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ABSTRACT 


In this thesis, we present the design of a software defined radio (SDR) transceiver 
using Open Source Software Communications Architecture (SCA) 
Implementation::Embedded (OSSIE) as the software platform. Designing a SDR requires 
both an appreciation of the IEEE 802.11a (wireless Local Area Network at 5 GHz band) 
protocol standard as well as the understanding of the C++ and CORBA software tools 
available to implement the physical transmitter and receiver layers. For this work, the 
Incremental Development Model was chosen, which is comprised of three stages: 
Design, Develop and Verify. The advantage of this model is its incremental nature, which 
allows the developer to learn from earlier versions of the system. Implementing the IEEE 
802.1la physical layer using OSSIE requires a total of 23 components, 12 different 
functionalities and 31 sequential input-output (I/O) processes for the transmitter, while 
the receiver is implemented with 18 components, 12 different functionalities and 20 
sequential I/O processes. The completed transmitter and receiver layers are validated 


successfully according to test cases stipulated in the IEEE standard. 
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EXECUTIVE SUMMARY 


Reed defines a software defined radio (SDR) as a radio that can be “substantially 
defined in software and whose physical layer behavior can be significantly altered 
through changes to its software”!. SDR has distinct military advantages over 
conventional radio as it promotes multi-functionality, mobility, compactness, flexibility, 


ease of manufacture and ease of upgrades. 


A military unit will not always know in advance what communications 
capabilities it will need in operations. This is especially true in coalition operations, 
where the coalition partner’s forces may not have the preferred radio equipment. 
Therefore, in operations, it is imperative to be prepared for many different means of 
communications, especially those that a coalition partner would be likely to possess. 
Radio equipment built to commercial (1.e., IEEE wireless) standards is just such a likely 
means of communications. SDR with the software to communicate in many modes, 
including commercial standards, would be a substantial advantage to a military unit that 
is part of a coalition operation, when time and foresight may not be sufficient for the 
fielding of communications equipment ideally suited for the specific coalition 
membership. For this research, the focus is on software design for the commercial 


standard IEEE 802.11a implemented on a SDR. 


In this thesis research, the transceiver components shall be implemented using 
software radio techniques. The components will be designed for use in an IEEE 802.11la 


transceiver and for contribution to the library of components being developed. The 


! J. H. Reed, “Software Radio: A Modern Approach to Radio Engineering”, Ist ed. New Jersey: 
Prentice Hall, 2002. 
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components developed shall be flexible so that they can be modified to implement other 
receivers by customizing the appropriate parameters. Design of the SDR shall use the 
Software Communications Architecture (SCA) including Common Object Request 
Broker Architecture (CORBA) as dictated for the Joint Tactical Radio System (JTRS). 
The components shall be tested based on functions and test cases found in the IEEE 


802.11a standard. 


For the transmitter, all functionalities from the input binary data to the digitized 
input to the Digital-to-Analog Converter (DAC) will be implemented in software. 
Similarly for the receiver, all functionalities after the Analog-to-Digital Converter (ADC) 
to the regeneration of the binary received information will be implemented in this thesis 
work. It is important to note that all software components are implemented at base band, 
i.e., before up-conversion at the transmitter and after down-conversion at the receiver. 

Following the principle of iterative and incremental development, five models 
have been developed, with each being more complex and built on the experiences 
gathered from the previous. The first three are exploratory models using MATLAB, 
which are relatively easy to build since many of the radio functionalities are already 
available as function calls. The fourth model builds on the success of the MATLAB 
design. It emulates a Transmitter-Receiver (Tx-Rx) design using Open Source SCA 
Implementation::Embedded (OSSIE) but following closely the previous MATLAB 
model. The final model is the full scale OSSIE implementation of IEEE 802.1la PHY 


layer, which is the primary objective of this thesis work. 
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In this thesis, we have successfully met the following objectives: 


1. The IEEE 802.11a PHY layer transmitter has been built using a total of 23 
OSSIE components with 12 different functionalities and 31 sequential I/O processes. 
Correspondingly, the receiver is implemented using 18 components with 12 different 


functionalities and 20 sequential I/O processes. 


2. All these components have been designed with modularity and flexibility in 
mind so that they contribute to the pool of components for future radio design. 
“Readme” files are also included in each component’s directory to explain its I/O data 
types, functionalities and assumptions. Appropriate parameters can be modified easily for 
use in other transceivers. All the files mentioned in this research have been included in 


the reference CD. 


3. With the design implemented fully in the OSSIE waveform development 
environment, the SDR conforms to Software Communications Architecture (SCA) and 
the Common Object Request Broker Architecture (CORBA). This will ensure flexibility, 


performance and maximum potential for software module reuse. 


4. Using the test cases provided in Annex G of the IEEE 802.1la standard 
document, all the components have been verified to provide the necessary functionalities 
expected of them. 

The software components developed here shall serve as a baseline to link up with 
other software or hardware components to implement a fully functional IEEE 802.11la 
transceiver. This functionality then can be added to any SDR that includes the minimum 
hardware functionality, (i.e. bandwidth, frequency band, sample rates, signal processing 


complexity) and conforms to the design standards specified by the JTRS JPEO in the 


X1X 


SCA, thereby providing that radio user one more mode of communications which extends 


readiness to include perhaps unanticipated communications demands. 
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I. INTRODUCTION 


A. OBJECTIVES 
In designing the software-defined radio (SDR), the following objectives have 


been identified: 


1. Design and implement transceiver components using soft radio techniques. 
The components will be designed for use in an IEEE 802.1la transceiver and for 


contribution to the library of components being developed. 


2. The components developed shall be flexible so that they can be modified to 


implement other receivers by customizing the appropriate parameters. 


3. Design of the SDR shall use the Software Communications Architecture (SCA) 
including Common Object Request Broker Architecture (CORBA) for flexibility, 


performance and maximum potential for software module reuse. 


4. The components shall be tested based on functions and test cases found in the 


IEEE 802.11a standard. 


B. GUIDING PRINCIPLES 

Designing a SDR requires both the appreciation of the protocol standard as well 
as the understanding of the software tools available to implement the physical transmitter 
and receiver layers (layer 1 under the OSI 7 layers model). In order to implement the 
coding effectively and efficiently within the limited amount of time, it is important that 
the whole research should be conducted with a set of guiding principles in mind. The 
following three are single out as critical factors guiding the research that has been carried 
out. 

1. Start Small 

Implementing the 802.1la physical layer using Open Source Software 
Communications Architecture (SCA) Implementation::Embedded (OSSIE) requires a 
total of 23 components, 12 different functionalities and 31 sequential input-output (I/O) 
processes for the transmitter, while the receiver is implemented with 18 components, 12 
different functionalities and 20 sequential I/O processes. It would be a daunting task to 
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jump straight into the coding of a full-scale IEEE 802.11a standard as it is extremely 


complex and would probably result in a demoralizing outcome. 


Hence, the strategy is to ‘start small’ by first developing simple components that 
work. This will help to build up confidence and experience in using the OSSIE software, 
which is still a trial version. This assimilation time is needed to understand the 
programming language and flow. An Incremental Development Model has been chosen 
for the software implementation as it advocates the need to be modular and provides 
constant feedback in the design cycle to minimize back tracing. It minimizes major bugs 
from occurring in the design further downstream in the implementation. More details on 


the model are provided in the next section. 


2. Think Modular 

As this research is more of a discovery venture (since it is the first time an attempt 
has been made to use OSSIE to implement IEEE 802.11a standards), the push for a direct 
working design outweighs the need for an efficient one. Hence, it is more important to 
get the various components under the standard to carry out their necessary functions, 
even though the code may not be written as efficiently as desired. If there is a need, 
future efforts can be recommended to optimize the code and integrate it with other 
aspects of the standards or hardware. These further enhancements are proposed in the 


concluding chapter. 


The targets to be modular and reusable reinforce the need to keep the components 
‘simple’ so that they can be understood and modified easily for future enhancement. 
While the OSSIE waveform developer already provides handy tools to modify 
components, it is critical to have good programming discipline in managing the 
complexity of the software algorithm. This prevents the code from getting too exclusive 


and losing the flexibility of customization. 


3. Help is Out There 
As mentioned before, OSSIE is still under development and refinement. It is very 


important that one is kept up to date regarding the OSSIE software development to fully 
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utilize its capabilities. Through the research, we have been fortunate to have constant 
dialogue and guidance from the OSSIE development team at the Virginia Polytechnic 


Institute and State University (Virginia Tech). 


The algorithm, functions and objects in the software are written in the C++ 
programming language. However, it is equally important to appreciate the underlying 
CORBA interfaces that enable input/output (I/O) interaction between components and 
integration of the transmitter and receiver waveforms. Another challenge will be to 
understand the IEEE 802.1la communication standard (e.g. modulation, error 
corrections, orthogonal frequency division multiplexing) and convert that into the desired 


algorithms in the C++ programming language. 


To fully understand the various technical details and challenges on one’s own is 
nearly impossible in such a short time. It has been important to seek assistance quickly 
whenever the implementation reached an obstacle. Proven algorithms and approaches are 
referenced so as not to reinvent the wheel. This research is also a collaboration with 
Major Low Kian Wai, who was working on the IEEE 802.16 implementation using 
OSSIE. Various useful resources include literature studies, Internet research, sample C++ 
software algorithms, MATLAB simulation for IEEE 802.11a standard, etc. All of these 
resources come disjointed but they provide guidance and the tools to complete the thesis 


research. 


C. INCREMENTAL DEVELOPMENT MODEL 

The intent of this model is to develop a software system incrementally, allowing 
the developer to take advantage of what has been learned in earlier versions of the 
system. The process starts with a simple implementation of a subset of the software 
requirements and iteratively enhances the evolving versions until the full system is 
implemented. At each iteration, design modifications are introduced and new functional 
capabilities are included [1]. The incremental development model has three stages: 
Design, Develop and Verify. Figure 1 describes the interrelationship between these three 
stages as a model and how it corresponds to processes in the software waveform 


development of the IEEE 802.1 1a standard. 
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Figure 1. Incremental Development Model.2 





ft. Design 
This stage starts with defining the outline software requirements and assigning 
these requirements to the specific increment. From these requirements, the system 


architecture is designed to serve as a framework for actual software development in the 


next stage. 





2 Eric Christensen, Elisa Wing, “Waveform application development process for software defined radios”, 
IEEE article, Motorola SSG and SPAWARSYSCEN, 2000: 234 
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2. Develop 

This is the actual ‘hands on’ of software development and programming, whereby 
the system requirements and pseudo-codes are converted to actual software languages. 
The coded algorithms are validated incrementally to ensure they meet the functionality 
expectations. Successful increments are stored for future use and new functionalities 


through design modifications are introduced for the next increment. 


J: Verify 

With the incremental development, the software system design gets larger and 
more complex. Increments shall be integrated in this stage and verified that the system as 
a whole is able to meet the holistic software requirements. For this research, the 
completed system must be able to emulate the IEEE 802.11a physical layer for both the 


transmitter and the receiver. 


D. THESIS CHAPTERS BREAKDOWN 
In this thesis, we present the approach of implementing a SDR transceiver using 
OSSIE as the software platform. This work has been divided into seven chapters. The 


following shows the focus of each chapter: 


Chapter I: Introduction. This chapter begins by giving an overview of the thesis 
objectives and follow by describing the guiding principles behind the design. The 
Incremental Development Model is also discussed to set the framework for subsequent 


chapters. 


Chapter II: Design. In this chapter, the key concepts stipulated in the thesis title 
are conveyed as requirements. Conceptual design using MATLAB models are discussed 
before the OSSIE detailed design model is presented. In the detailed design, transmitter 


and receiver models are discussed separately. 


Chapter III: Develop — Transmitter. The design of the transmitter is presented 
in this chapter. The discussion is divided into preamble, SIGNAL and DATA subframes. 
It ends with the design of concatenating the three subframes to form the PPDU frame. 
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Chapter IV: Develop — Receiver. The design of the receiver is presented in this 
chapter. Similar to the transmitter, the chapter is divided into preamble, SIGNAL and 
DATA subframes. 


Chapter V: Challenges. The IFFT/FFT and Viterbi decoder are singled out as 
special interest components as their design are both involved and complex. Difficulties 


and peculiarities of OSSIE software are also mentioned. 


Chapter VI: Verify. Testing of the final product is carried out with reference to 
the IEEE 802.11a standard. The test results for both transmitter and receiver models are 


presented in this chapter. 


Chapter VII: Conclusion. This chapter gives a review on the thesis objectives 
and provides recommendations on potential future work with the baseline components 


developed. 


Il. DESIGN 


A. REQUIREMENTS ANALYSIS 

In order to meet the thesis objectives, it is important to fully understand the 
concepts underlying base on the thesis topic — “Software Defined Radio design for an 
IEEE 802.1lla Transceiver using OSSIE’’. The three important concepts are Software 
Defined Radio, the IEEE 802.11a wireless standard and OSSIE. In the following section, 
these three concepts are presented in sufficient detail to set the design boundaries. This 
shall lead to the conceptual design of the eventual software architecture. 

1. Software Defined Radio 

SDR refers to a radio that can be “substantially defined in software and whose 
physical layer behavior can be significantly altered through changes to its software” [2]. 
SDR has advantages over conventional radio as it promotes multi-functionality, mobility, 
compactness, ease of manufacture and ease of upgrades. The design of a SDR generally 
comprises a series of procedures that include system engineering, RF chain planning, 
Analog-to-Digital and Digital-to-Analog hardware selections, software and hardware 
architecture selection and radio validations. For this research, the focus is only on 


software architecting according to a specific standard — IEEE 802.1 1a. 


The extent of software architecting or the boundary where software algorithms 


shall be written is shown in Figure 2. 


Receiver 


5 Down 





Software 


Architecture 


: Up 








Figure 2. Model of Software Defined Radio. 


For the transmitter, all functionalities from the input binary data to the digitized 
input to the Digital-to-Analog Converter (DAC) will be implemented in software. 
Similarly, for the receiver, all functionalities after the Analog-to-Digital Converter 
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(ADC) to the regeneration of the binary received information will be implemented in this 
thesis work. It is important to note that all software components are implemented at base 
band, i.e., before up-conversion at the transmitter and after down-conversion at the 
receiver. 

2. IEEE 802.11a PHY Layer 

The physical standard takes reference from Partl1: IEEE Std 802.11la-1999 
(Revision 2003) [3]. It describes the wireless LAN Medium Access Control (MAC) and 
Physical Layer (PHY) specifications, specifically for high-speed physical layer in the 5 
GHz band. Since the following implementation is done at base band, the carrier 
frequency of approximately 5 GHz band is immaterial. IEEE 802.1la is based on 
Orthogonal Frequency-Division Multiplexing (OFDM) whereby a single transmission 1s 
encoded into multiple subcarriers. Section 17 of the standard (OFDM PHY specification 
for the 5 GHz band) is the working document upon which this thesis’s algorithm is based. 
A simplified explanation of the working of the OFDM PHY layer can also be found in 


reference [4]. 
Important design requirements of an IEEE 802.11a PHY system are as follows: 


a) data payload communication capabilities of 6, 9, 12, 18, 24, 36, 48, and 54 
Mbits/s 


b) mandatory transmitting and receiving at data rates of 6, 12, and 24 Mbits/s 


c) 52 subcarriers that are modulated using binary or quadrature phase shift 
keying (BPSK/QPSK), 16-quadrature amplitude modulation (QAM), or 64- 
QAM. 


d) Forward error correction coding (convolutional coding) with a coding rate of 


1/2, 2/3, or 3/4. Viterbi decoding will be implemented at the receiver. 
e) 1 OFDM symbol per 4 Us (250, 000 sym/s) 


The IEEE 802.11a PHY layer consists of two core sub-layers: Physical Layer 
Convergence Procedure (PLCP) and Physical Medium Dependent (PMD) layer. The 


PLCP maps the MAC frames onto the medium and serves as the boundary between the 


MAC and PHY layers. The PMD layer carries out the actual transmission of these 


frames. 


During transmission, multiple PHY sublayer Service Data Units (PSDUs) 
cascaded down from the MAC layer shall be appended with a PLCP preamble and header 
to form the PLCP Protocol Data Unit (PPDU). At the receiver, the PLCP preamble and 
header are retrieved and important information is extracted to help in the delivery of the 
PSDUs. For this thesis, the aim is to provide a software procedure in which PSDUs are 
converted to and from PPDUs. The format for the PPDU including the PLCP preamble, 
PLCP header, PSDU, tail bits, and pad bits are shown in Figure 3. 



































\ PLCP Header I 
~~ | 
RATE | Reserved] LENGTH] Parity | Tail | SERVICE « Tail Sees 
4bits | 1bit | 12 bits | Lbit | 6bits| 16 bits cas | 6 bits |Pao a 
ie 1 
— Coded/OFDM | Coded/OFDM | 
s * (BPSK, r= 1/2) | (RATE is indicated in SIGNAL) | 
| 





PLCP Preamble DATA 
12 Symbols One OFDM Symbo Variable Number of OFDM Symbols 





Figure 3. PPDU frame format (from: reference [3], Fig 107). 


The LENGTH, RATE, reserved bit, parity bit and six “zero” tail bits are 
modulated to form a single OFDM symbol known as SIGNAL. This symbol is 


1 : 
transmitted using BPSK modulation and a coding rate of R= = The SERVICE field of 


the PLCP header, the PSDU, six “zero” tail bits and the necessary pad bits are modulated 
to form multiple OFDM symbols that is collectively known as DATA. DATA is 
transmitted at a data rate according to the RATE field and the LENGTH field determines 
the number of OFDM symbols in DATA. Hence, the RATE and LENGTH fields are 
critical in decoding the DATA part of the packet. 

3. OSSIE Platform 

The Open Source SCA Implementation::Embedded (OSSIE) is developed by the 
Mobile and Portable Radio Research Group (MPRG) at Virginia Tech as an open source 
SCA Core Framework solution. OSSIE was created to meet the need for a C++-based, 


open source SCA implementation that could be modified and adapted in a research 
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environment. The current version of OSSIE (0.5.0) is based on version 2.2.1 of the SCA 
specification. A detailed presentation of the OSSIE platform can be found in Jacob A. 
DePriest’s thesis entitled “A Practical Approach to Rapid Prototyping of SCA 
Waveforms” at Virginia Tech [5]. From his thesis, the reader would be able to appreciate 
the OSSIE Waveform Developer (OWD) environment, specifically the following 


knowledge: 


a) able to customize and design OSSIE components according to specific port 


implementation and inter-components threading strategies 
b) able to set up device assignment to each component being developed 


c) able to design a waveform using OWD to map a Radio design to the OSSIE 


software components available 


This thesis is written with the assumption that the reader has certain prior 
knowledge about the C++ programming language, including object-oriented design. 
There are four important C++ files generated for each new component: <Component 
Name>.h, <Component Name>.cpp, port_impl.h and port_impl.cpp. These are where the 
functionalities are defined for the component. The content of these generated C++ files 


are modified to provide the actual functionality of a radio component. 


a) port_impl.h and port_impl.cpp: implement the port communication between 


components, determining what is to be received and sent 


b) <Component Name>.h and <Component Name>.cpp: ‘brain’ of the 
component, where its functionalities are programmed. Most of the post- 
generation codes are resided in the process_data() function call within 
<Component Name>.cpp. 

B. CONCEPTUAL DESIGN 

Following the principle of iterative and incremental development, five models 
have been developed, with each being more complex and built on the experiences 
gathered from the previous. The first three are exploratory models using MATLAB, 
which are relatively easy to build since many of the radio functionalities are already 


available as function calls. The fourth model builds on the success of the MATLAB 
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design. It emulates a Transmitter-Receiver (Tx-Rx) design using OSSIE but following 
closely the previous MATLAB model. The final model is the full scale OSSIE 
implementation of IEEE 802.11a PHY layer, which is the primary objective of this thesis 
work. A summary of the models is provided in Figure 4. The first four models are 
described here to demonstrate the incremental approach, while Section C presents the 


final full scale model. 





Figure 4. Incremental conceptual design. 
1. MATLAB OFDM Models 


An OFDM transmission design was implemented using MATLAB according to 


the source code recommended by Hiroshi and Ramjee [6]. There are three MATLAB 
models implemented, namely BPSK, QPSK and OFDM transceivers. 

a. BPSK Modulation / Demodulation Transceiver 

A block diagram of the design is shown in Figure 5. A simple BPSK 
modulation / demodulation was implemented to demonstrate the sequential flows of data 
between transmitter and receiver. A description of each component is provided in Table 


1. The main MATLAB file that calls the various functions is mainBPSK.m. 
















































































(Indata) (Data) (BiPolar) 
dataGen ;—————> biPolar —————— tx MF 
10114} cr] cleat) 
|filterRRC | | channel | 
(Rxh) 
(RxBinData)| thresholdDet «————F rxSample *————_F rxMF 
(RxSampledData) (RxData) (digitisedData) 


Figure 5. MATLAB BPSK transceiver model. 
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Filename —__|Purpose 
ddataGen generate the tx binary data 




















biPolar convert binary to polar data 

txMF Tx pulse-shaping using root raised cosine 
filterRRC generate coefficients of Nyquist filter 

channel model channel distortion (e.g. AWGN, fading) 
rxMF Rx pulse-shaping using root raised cosine 





rxSample_ _|sample the matched filter outputs 
thresholdDet |threshold detector using Comparator 
Table 1. | MATLAB BPSK transceiver components description. 

















b. QPSK Modulation / Demodulation Transceiver 
Next, a QPSK modulation / demodulation was implemented. The block 
diagram and components description are shown in Figure 6 and Table 2, respectively. 


The main MATLAB file that calls the various functions is mainQPSK.m. 




















































































































(Indata = 1) (Data) (ichData) (ich TxData) 
dataGen txlQ | ————$ | tx MF 
(qchData) x (qchTxData) 
{1011000114} (Txh) 
filterRRC channel 
(Rxh) 
(ichRxSampledData) ae (ichRxData) ti |lichDigitisedData) 
(qchRxData) (qchDigitisedData) 
(qchRxSampledData) 
rxlQ thresholdDet | (RxBinData) 




















(demoData) 
Figure 6. MATLAB QPSK transceiver model. 



































Filename Purpose 

dataGen enerate the tx binary data 

txlQ generate | and Q channel signals for QPSK (serial to parallel) 
txMF Tx pulse-shaping using root raised cosine 

filterRRC generate coefficients of Nyquist filter 

channel model channel distortion (e.g. AWGN, fading) 

rxMF Rx pulse-shaping using root raised cosine 

rxSample Sample the matched filter outputs 

rxlQ demodulate | and Q channels signals for QPSK (parallel to serial) 
thresholdDet threshold detector using Comparator 











Table 2. . MATLAB QPSK transceiver components description. 
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c. OFDM Transceiver 

The final design was an attempt to implement QPSK modulation with 
OFDM using MATLAB. The block diagram and component descriptions are shown in 
Figure 7 and Table 3, respectively. This design is the closest to the IEEE 802.1la PHY 
layer with many familiar functions that would eventually be ‘converted’ to components in 
OSSIE. These important functions include modulation mapping, normalization, inverse 
fast Fourier transform (IFFT) for OFDM, guard insert (or cyclic prefix insert) for the 
transmitter and demodulation mapping, unnormalization, fast Fourier transform (FFT) for 
OFDM and guard removal (or cyclic prefix removal) for the receiver. The main 


MATLAB file that calls the various functions is mainOFDM.m. 





































































































































































































(Indata = 2) (serialTxData) (paraData) (Ich) 
dataGen }—— s/p SS QpskMod (Och) | 
{1 x para x nd x ml} {para x (nd x ml)} 
Normalize 
ch [oon 
(iTxG) (iIFFT) 
Guardrem #22zcz2zz==7) channel #22===0229 Guarding {—————— |FFT 
(qTxG) 
(iRxG) \| (qRxG) (qIFFT) 
FFT thresholdDet | (RxBinData) 
GFET) | |GFFT) chun) (para x (nd x mi)}_[(serialFxData) 
UnNormalize QpskDemod | ————-$ | p/s 
(QchUn) peoreraarnd 
(parallelRxData) 
Figure 7. MATLAB OFDM transceiver model. 
Filename Purpose 
OFDMdataGen generate initial serial binary data 
SerToPara serial to parallel conversion 
QpskMod perform QPSK modulation 
Normalize Normalize the tx data 
IFFT IFFT for the Tx data 
GiINS insert guard interval into transmission signal 
GiRem remove guard interval from received signal 
FFT FFT for the Rx data 
UnNormalize — |UnNormalize the rx data 
QpskDemod __ perform QPSK demodulation 
ParaToSer arallel to serial conversion 
ThresDetO threshold detector using Comparator 














Table 3. |. MATLAB OFDM transceiver components description. 
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The above three models provide a good stepping stone to the implementation of 
an OSSIE transceiver since they remove many of the complex software coding that is 
needed to implement the various functions. For example, IFFT and FFT are built-in 
functions in MATLAB, while direct coding is needed in C++ when OSSIE is used. More 
time can be spent on appreciating the data flow between components rather then 
worrying about coding the functionalities, i.e., understanding the functionalities is 
priority over coding the functionalities. All the necessary MATLAB files to implement 


the above three designs have been included in the reference CD. 


2. OSSIE Tx-Rx OFDM Model 

With a better understanding of the generic OFDM transceiver using MATLAB, 
the design shown in Figure 7 is ported over to OSSIE. All the functionalities are 
implemented as separate OSSIE components with the addition of two new components to 
demonstrate the inclusion of pilot subcarriers: carrier mapping (crMapping) and 
demapping (crDemapping). Their functionalities are summarized in Table 4. Detailed 
descriptions of each component shall be presented in the next two chapters under the full 


scale IEEE 802.11a implementation. 





Filename Purpose 





crMapping adds pilot subcarriers to the modulated data prior to IFFT processing 











crDeMapping |removes pilot subcarriers from the FFT output prior to demodulation. 
Table 4. | OSSIE OFDM model additional components. 





This intermediate model bridges the gaps between the MATLAB design and an 
OSSIE waveform where most of the functionalities have to be coded instead of 
depending on C++ built-in functions. Challenges in programming under the OSSIE 
environment begin to surface in this stage. Important programming experiences and 
lessons learned are described in the later chapters of this thesis. All the necessary OSSIE 
component and waveform files to implement the OFDM transceiver model have been 


included in the reference CD. 
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C. DETAILED DESIGN: OSSIE IEEE 802.11A TRANSCEIVER MODEL 

The full scale 802.1la PHY layer is based on the IEEE standard 802.11a-1999 
(Revision 2003) [3]. Design requirements are summarized in Section A.2 of this chapter. 
There are two core system architectures — transmitter and receiver. Both are implemented 
in software under the OWD environment. 

iF Transmitter 

The transmitter converts the binary inputs (especially the PSDU information from 
the MAC layer) into digitized PPDU frames to be passed through the DAC before up- 
conversion for RF transmission. According to Figure 3, the PPDU frame can be 
subdivided into three ‘subframes’, namely PLCP preamble (or just preamble), PLCP 
header excluding SERVICE (or just SIGNAL) and DATA. These represent the three 
separate ‘modules’ that shall be developed and appended to form the eventual transmitter 
PPDU frame. The components are developed either to carry out specific functions or to 
form the frames/subframes. The types of component needed are described in the 


components flow diagram of Figure 8. 


T f componen Up-convert 


RF (5GHz) 


Software | Hardware 



















Tx2: 
Form SIGNAL 
\ (PLCP headen) | 






| Form PLCP 
preamble 





t 

1 

' 

' 

} 

Tx8: ' 
Modulation ; 
mapping ' 
' 

' 

' 

' 












Tx9: 
Carriers 
mapping 


Windowing 
(not 
implement) 





Guard insert 
(cyclic prefix) 






Figure 8. IEEE 802.11a Transmitter components flow diagram. 
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Figure 8 shows that twelve types of components (Txl — Tx12) are needed. 
Equally important is the fact that components of the same type are being reused in 
different subframes. For example, all three subframes employ the carriers mapping 
(Tx9), IFFT (Tx10) and cyclic prefix (Tx11) components, while only SIGNAL and Data 
subframes require the convolution encoder (Tx6), interleaver (Tx7) and modulation 


mapping (Tx8) components. 


Note that windowing is not implemented as it is implementer specific and can be 
customized easily using software when needed. Time domain windowing was proposed 
in the IEEE 802.1la standard but it is just an informative rather than a mandatory 
approach. The implementer may choose other methods to achieve the purpose of 


smoothening the transitions between segments, such as frequency domain filtering. 


Another way of representing the schematic is to describe the processing flow of 
each subframe separately as shown in Figure 9. This provides a better pictorial view of 
the functional flow for the formation of each subframe. It shows the sequential 
development of the PPDU frame. Figure 9 shows the quantity of each type of component 
that is needed to implement the transmitter. For example, four carriers mapping (Tx1.1.9, 
Tx1.2.9. Tx2.9 and Tx3.9) components are needed, while two convolution encoder 


(Tx2.6 and Tx3.6) components are necessary. 
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Figure 9. 
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IEEE 802.11a Transmitter subframes flow diagram. 


A summary of the functionalities of each component is provided in Table 5. The 


index abides by the following naming convention: 


a) The first digit from the left represents the frame or subframe that the 
component belongs to. An exception is the preamble training sequences 
whereby Tx1.1.x represents component that forms the short training sequence 


and Tx1.2.x represents component that forms the long training sequence. 










































































First digit Frame / subframe 
0 PSDU 
1 preamble subframe 
2 SIGNAL subframe 
3 DATA subframe 
12 PPDU 
b) The last digit from the left represents the function of the component. 
Last digit Function 
0 PSDU formation 
i preamble subframe formation 
2 SIGNAL subframe formation 
| DATA subframe formation 
4 Scrambler 
5 Tail-replacement 
6 Convolution encoder 
7 Interleaver 
8 Modulation 
9 Carriers mapper 
10 IFFT 
11 Cyclic prefix 
12 PPDU formation 














For illustrations, Tx2.7 indicates a component under the SIGNAL subframe (2) 


that carries out the interleaving (7) function. 
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Index Component Functions 

Preamble subframe 

Tx1 preamble_map - initiate the Tx routine 
- form short training (ST) and long training (LT) sequence 
- send preamble (ST + LT) to PPDU 

Tx1.1 short training (ST) 

Tx1.1.9 ST_carrier_map - ST carrier mapping 

Tx1.1.10 ST_IFFT - ST IFFT 

Tx1.2 long training (LT) 

Tx1.2.9 (LT_carrier_map - LT carrier mapping 

Tx1.2.10 LT_IFFT - LT IFFT 

Tx1.2.11 |LT_cyclicPrefix - LT cyclic prefix append 

SIGNAL subframe 

Tx2 header_map - form SIGNAL (SIG) samples 

(SIGNAL_map) - send SIG to PPDU 

Tx2.6 SIG_conv_enc - SIG convolution encoding 

Tx2.7 SIG_interleaver - SIG interleaving 

Tx2.8 SIG_BPSK_mod - SIG BPSK modulation 

Tx2.9 SIG_carriers_map - SIG carriers mapping 

Tx2.10 SIG_IFFT - SIG IFFT 

Tx2.11 SIG_cyclicprefix - SIG cyclic prefix 

DATA subframe 

Tx3 data_map - form time data samples from PSDU 
- send DATA samples to PPDU 

TX3.4 data_scrambler - scrambler the raw data 

Tx3.5 data_tail_replacement _|- replace tail with zeroes 

Tx3.6 data_conv_enc - data convolution encoding 
- data puncturing 

TX3.7 data_interleaver - data interleaving 

TX3.8 data_mod_map - data modulation mapping 

TX3.9 data_carriers_map - data carriers mapping 

Tx3.10  (data_IFFT - data IFFT 

Tx3.11 data_cyclicprefix - data cyclic prefix 

Tx12 PPDU_map - form PPDU frame from Preamble, SIG and DATA 
subframes for transmission 

Tx0 data_PSDU - input PSDU data 

Table 5. [EEE 802.11a Transmitter components functionalities. 
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2. Receiver 

The receiver carries out almost the inverse functions of the transmitter. In the 
receiver, digitized PPDU frames (passed down from the ADC after down-conversion 
from the RF front end) shall be converted into binary outputs from which the original 
PSDU information can be extracted. Like the transmitter, the receiver is comprised of 
three separate ‘modules’, namely preamble, SIGNAL and DATA subframes. The type of 
components needed are described in the components flow diagram of Figure 10. In 
comparison, fewer components are needed to implement the receiver than transmitter, but 


the receiver entails more complexity in the C++ algorithm. 


Types of component 


Down-convert 








Rx5: 
Tail 
replacement 





Rx6: : : 
Convolution |<! Demodulation |< | 
decoder mapping Ii 


RES ait Windowin , 
Carriers _—: - —| Guard remove . g 
demapping (cyclic prefix) 


(not implement) 


Figure 10. IEEE 802.11a Receiver components flow diagram. 
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Figure 10 shows that twelve types of components (Rx1 — Rx12) are needed. Note 
that Rx1 (PLCP preamble retrieval) and Rx12 (PPDU retrieval) are implemented in the 
same component. Synchronization is possible by assuming that the digitized samples 
received from the RF front end are compared to a fixed reference copy of the PLCP 
preamble sequence. Hence, from the PPDU stream, the entire received preamble 
sequence is identifiable, and this shall lead to the retrieval of the SIGNAL and DATA 
subframes. Detailed implementation of this component is described in Chapter IV, 


Section A2. 


Like the transmitter, components of the same type are being reused in different 
subframes. For example, both SIGNAL and DATA subframes employ the carriers 
demapping (Rx9), FFT (Rx10) and cyclic prefix removal (Rx11) components, while only 
Data subframes require the descrambler (Rx4) component. Note that windowing is again 


not implemented, as it is implementer specific. 


An alternate view of the schematic is to describe the processing flow of each 
subframe separately as shown in Figure 11. This shows the functional flow for the 
separation of each subframe and the eventual retrieval of the PSDU. Figure 11 shows the 
quantity of each type of component that is needed to implement the receiver. For 
example, two carriers demapping (Rx2.9 and Rx3.9) components are needed, while one 


descrambler (Rx3.4) component is needed. 


ea 
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DeScrambler 
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replacement 
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mapping mapping 


Rx2.9: Rx3.9: 
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(cyclic prefix) (cyclic prefix) 





Figure 11. [EEE 802.11a Receiver subframes flow diagram. 
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The functionalities of each component are provided in Table 6. Similar to the 


transmitter, the receiver’s component index abides by the following naming convention: 


a) The first digit from the left represents the frame or subframe that the 


component belongs to. 





First digit Frame / subframe 





Received digitized samples 





0 

1 preamble subframe 
2 SIGNAL subframe 
é DATA subframe 
12 PPDU 























b) The last digit from the left represents the function of the component. 





Last digit Function 





Digitized samples retrieval 





preamble subframe retrieval 
SIGNAL subframe retrieval 
DATA subframe retrieval 











Descrambler 





Tail-replacement 





Convolution decoder 





Deinterleaver 





Demodulation 





OO | IN ID [On JH JW TY [RY |oO 


Carriers demapper 


FFT 





— 
o 





_— 
— 


Cyclic prefix removal 


PPDU retrieval 














— 
Nw 





For example, Rx3.7 indicates a component under the DATA subframe (3) that 


carries out the deinterleaving (7) function. 
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Index Component Functions 
Preamble subframe 
Rx0 Rx_data - received digitized data stream 
Rx1/Rx12 PPDU_rx - extract the required digitized PPDU stream 
- removed preamble from PPDU 
- send stream for header removal 
SIGNAL subframe 
Rx2 Header_rx - removed header from PPDU 
(SIGNAL_rx) - send header for processing 
- extract RATE & LENGTH from SIG 
- send received data for processing 
Rx2.11 SIG_cyclicprefix_rem - SIG cyclic prefix removal 
Rx2.10 SIG_FFT - SIG FFT 
Rx2.9 SIG_carriers_demap - SIG carriers demapping 
Rx2.8 SIG_BPSK_demod - SIG BPSK demodulation 
Rx2.7 SIG_deinterleaver - SIG deinterleaving 
Rx2.6 SIG_conv_dec - SIG convolution decoding 
DATA subframe 
Rx3 data_rx - receive and send raw data for processing 
- receive and send PSDU data to MAC layer 
Rx3.11 data_cyclicprefix_rem | - data cyclic prefix removal 
Rx3.10 data_FFT - data FFT 
Rx3.9 data_carriers_demap - data carriers demapping 
Rx3.8 data_demod_map - data demodulation mapping 
Rx3.7 data_deinterleaver - data deinterleaving 
Rx3.6 data_conv_dec - data dummy insertion 
- data convolution decoding 
Rx3.5 data_tail_replace - not required, encompass in descrambler 
Rx3.4 data_descrambler - descrambler the raw data 

















Table 6. [EEE 802.11a Receiver components functionalities. 


In the next two chapters, the developmental details of each transmitter and 
receiver component are presented. The focus is on the C++ algorithm that implement the 
various functionalities. These functionalities are developed according to Table 5 and 


Table 6. 
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Wf. DEVELOP: TRANSMITTER 


This and the next chapter provide the developmental details of the components in 
the transmitter and receiver to model the IEEE 802.11a PHY layer. In this chapter, the 
first three sections describe the three subframes of the transmitter: preamble, SIGNAL 
and DATA. The last section describes how the subframes are concatenated to form the 
PPDU. Components are described according to the inter-linkages of the input-output 


(I/O) ports and the functional implementation in C++ code. 


The transmitter converts the binary inputs (especially the PSDU information from 
the MAC layer) into digitized PPDU frames to be sent through the DAC before up- 
conversion for RF transmission. The incremental development is discussed here starting 
with the preamble subframe, followed by SIGNAL subframe and, finally, the overall 
PPDU frame with the inclusion of the DATA subframe. 


A. PREAMBLE 

The PLCP preamble subframe consists of ten repetitions of a short training (ST) 
sequence and two repetitions of a long training (LT) sequence, preceded by a guard 
interval (cyclic prefix). The format for the PLCP preamble subframe is presented in 
Figure 12. Table 7 summarizes the OSSIE components needed to form the preamble 


subframe. 
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Figure 12. | PPDU frame structure and timing. (from: reference [3], Fig. 110). 
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Index Component Functions 

Tx preamble_map - initiate the Tx routine 

- form short training (ST) and long training (LT) sequence 
- send preamble (ST + LT) to form PPDU 








Tx1.1 short training (ST) 
Tx1.1.9 |ST_carriers_map |- ST carriers mapping 
Tx1.1.10 ST_IFFT - ST IFFT 

Tx1.2 long training (LT) 
Tx1.2.9 |LT_carriers_map |- LT carriers mapping 

Tx1.2.10 |LT_IFFT - LT IFFT 

Tx1.2.11 |LT_cyclicPrefix - LT cyclic prefix append 

Table 7. | IEEE 802.11a Transmitter preamble subframe components functionalities. 



































i, Tx1: Preamble Mapping (Assembly Controller) 


Component name: preamble_map 





Port design: preamble_map is the assembly controller for the transmitter. 
Assembly controller is the only component within each model where the start() function 
is being called when the waveform is first loaded. When it is time to start the radio, the 
assembly controller’s start() function shall initiate the transmitter software routine to 
form the PPDU frame. It has a total of 2 input ports where data is flowing into the 
component (S7_input and LT_input) and 3 output ports where data is flowing out of the 
component (ST_processing, LT_processing and preamble subframe). Figure 13 shows the 
I/O distribution of the component. 


Legends 











External Task in 
component etna Function ca the function 1/0 port 
Tx1: preamble_map 


ana] >) Call ST processing >| Store ST sequence - Call LT processing —— ba LT sequence }— 
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Preamble 
ST_processing LT_processing 
a: 
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Es Ae Tx1.1. a Tx1.1.2.9: 7x1.1.2.11: Ea 
Es carriers_map ST_| ae LT_carriers_map LT_cyclicPrefix Ea | map 


Figure 13. | preamble_map port and functional flow. 
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Functional design: preamble_map carries out three main functions: (1) initiate 
the transmitter routine, (2) form ST and LT sequences, and (3) append the two sequences 
and form the preamble subframe. This sequential functional flow is shown in Figure 13. 
After the initiation from the start() function, process_data() is called to start the ST 
processing. The ST_processing output port is activated to push the relevant packets to 
another component, S7_carriers_map, which carries on with the formation of ST 
sequences. Eventually, the processed ST sequence shall be routed back to preamble_map 
component from ST_IFFT component via the ST_input input port. The same approach is 
carried out to generate the LT sequence by using the LT_processing output port and 
LT_input input port to connect to LT_carriers_map and LT_cyclicPrefix component 
respectively. With the two sequences generated and attached to each other, the final data 


is pushed to PPDU_map component via the preamble_subframe output port. 


2. Tx1.1.9: Carriers Mapping (ST) 


Component name: ST_carriers_map 





Port design: ST_carriers_map has 1 input port and | output port. Figure 14 shows 
the I/O distribution of the component. 


Functional design: Its main function is to re-index and normalize the 52 





subcarriers of the initial short training sequence as part of the 64 frequency samples (by 


introducing guard bands as stipulated in the IEEE standard) to serve as input into the 


IFFT component. The functional flow is shown in Figure 14. 


Tx1.1.9: ST_carriers_map 





| ; Tx1.4.9-11: 
crMap_input 
Process data () ——| Re-indexing 4 Normalize — Txt 19-01; 
ae crMap_output 
y 
Tx1.1.10: 
ST_IFFT 


Figure 14. ST_carriers_map port and functional flow. 


~\ 
Txt: 
preamble_map 
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5 Tx1.1.10: IFFT (ST) 
Component name: ST_IFFT 





Port design: ST_JFFT has 1 input port and | output port. Figure 15 shows the I/O 





distribution of the component. 


Functional design: The component emulates OFDM processing through a 
software IFFT algorithm. From S7_carriers_map, 64 frequency samples shall be sent 
through ST_IFFT to convert to 64 time samples. In this implementation the Decimation- 
In-Time (DIT) Permutated Input - Natural Output (PINO) IFFT algorithm [7] is selected 
as it is reasonably easy to comprehend and code. The time samples need to be duplicated 
10 times to form the necessary sequence length for the preamble subframe. The 
functional flow is shown in Figure 15. The DIT PINO IFFT algorithm has been singled 


out as special interest component that shall be described in Chapter V. 


Tx1.1.10: ST_IFFT 





Tx1.1.9: — 
ST_carriers_map _ 
Convert input to : \ Tx1.1.10-O1: 
Process data () + complex (1/Q) freq >) Bit reverssal ak e IFFT ok 
| : samples ~ 
axa 
preamble_map 


Figure 15. | ST_IFFT port and functional flow. 


4. Tx1.2.9: Carriers Mapping (LT) 


Component name: LT_carriers_map 





Port design: LT_carriers_map has | input port and | output port. Figure 16 shows 





the I/O distribution of the component. 


Functional design: Similar to its ST counterpart, LT_carriers_map re-indexes the 
52 subcarriers of the initial long training sequence as part of the 64 frequency samples 
(by introducing guard bands as stipulated in the IEEE standard) to serve as input into the 


IFFT component. The functional flow is shown in Figure 16. 
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Tx1.2.9: LT_carriers_map 
| Tx1.2.9-11: 
| crMap_input 
‘ 4 . : Tx1.2.9-01: fe Tx1.2.10: 
| Process data () ; | crMap_output | LT_IFFT 


Figure 16. | LT_carriers_map port and functional flow. 





Tx1: \ 
preamble_map 


5. Tx1.2.10: IFFT (LT) 
Component name: LT_IFFT 


Port design: LT_IFFT has | input port and | output port. Figure 17 shows the I/O 


distribution of the component. 


Functional design: Like ST_IFFT, this component emulates OFDM processing 
through software IFFT algorithm. From LT_carriers_map, 64 frequency samples will be 
sent through LT_IFFT to convert to 64 time samples. The DIT PINO IFFT algorithm 


shall be described in Chapter V. The time samples are duplicated twice before inserting a 


cyclic prefix in the next component. The functional flow is shown in Figure 17. 


xd2a0;7 IEE 






[ 
Tx1.2.9: = 
LT_carriers_map 
Convert input to “ait | 
Process data () complex (I/Q) freq 1 Bit reverssal Pen pati aerate | 
samples —oulp | 
Tralee 
LT_cyclicPrefix 


Figure 17... LT_IFFT port and functional flow. 


6. Tx1.2.11: Cyclic Prefix (LT) 
Component name: LT_cyclicPrefix 
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Port design: LT_cyclicPrefix has 1 input port and | output port. Figure 18 shows 


the I/O distribution of the component. 


Functional design: LT_cyclicPrefix prefixes half the length of one full IFFT time 





samples to the data to form the LT sequence. This sequence is forwarded to 


preamble_map and appended to the ST sequence as preamble subframe. The functional 


flow is shown in Figure 18. 


1x1.2.11: LT_cyclicPrefix 













wp / Tx1.2.41-11: 
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i | by (IFFT_len/2) 


Figure 18. | LT_ cyclicPrefix port and functional flow. 








Process data () [——~ 





B. SIGNAL 
The SIGNAL symbol consists of RATE and LENGTH fields that are encoded by 


a convolutional code of R= 7 It is subsequently mapped onto a single OFDM symbol 


with BPSK sub-channel modulation. The encoding of the SIGNAL field into an OFDM 
symbol follows the procedures: convolutional encoding, interleaving, BPSK modulation, 
pilot insertion (guard band), IFFT and appending a cyclic prefix at a data rate of 6 
Mbits/s. Unlike the DATA subframe, the information bits of the SIGNAL field are not 


scrambled. Table 8 summarizes the components needed to form the SIGNAL subframe. 














Index Component Functions 

Tx2 header_map - form SIGNAL (SIG) samples 
(SIGNAL_map) - send SIG to form PPDU 

Tx2.6 SIG_conv_enc - SIG convolution encoding 

Tx2.7 SIG_interleaver - SIG interleaving 





Tx2.8 SIG_BPSK_mod_|- SIG BPSK modulation 

Tx2.9 SIG_carriers_map |- SIG carriers mapping 

Tx2.10 |SIG_IFFT - SIG IFFT 

Tx2.11  |SlG_cyclicprefix | - SIG cyclic prefix 

Table 8. | IEEE 802.11a Transmitter SIGNAL subframe components functionalities. 
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1. Tx2: SIGNAL Mapping 
Component name: SIGNAL_map 





Port design: SIGNAL_map has a total of 2 input ports and 2 output ports. Figure 


19 shows the I/O distribution of the component. 


Functional design: SJGNAL_map carries out the function of concatenating 
important parameters (especially RATE and LENGTH) and sending it for processing to 
form an OFDM symbol at a data rate of 6 Mbits/s. At this data rate, the modulation type 
and data structure are fixed as shown in Table 9. RATE and LENGTH can either be 


passed down from the MAC layer or entered by other means. 


The final symbol shall form the SIGNAL subframe to be transmitted as part of 
PPDU. The SIGNAL field is composed of 24 bits, as shown in Figure 20. Bits 0 to 3 shall 
represent the RATE. Bit 4 is reserved for future use. Bits 5 to 16 shall represent the 
LENGTH field, with the least significant bit (LSB) being transmitted first. The 


component functional flow is shown in Figure 19. 


























Data rate Modulation Coding rate Coded bits Coded bits Data bits 
Mbi R Per per OFDM per OFDM 
( bits/ s) ( ) subcarrier symbol symbol 
(Nps) CN ices ) UN jars ) 
6 BPSK 1/2 1 48 24 
Table 9. | Rate-dependent parameters: 6 Mbits/s. 
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SIGNAL_map port and functional flow. 
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Figure 19. 
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Transmit Order 
Figure 20. | composition of SIGNAL field (from: reference [3], Fig. 111). 


2. Tx2.6: Convolutional Encoder (SIG) 


Component name: SIG_conv_enc 





Port design: $JG_conv_enc has 1 input port and 1 output port. Figure 22 shows 





the I/O distribution of the component. 


Functional design: The SIGNAL field is coded with a convolutional encoder to a 
coding rate of R =>. The convolutional encoder is shown in Figure 21 with the two 
generator polynomials stated in the IEEE 802.11a standard (g, =133, and g, =171,) 
and a fixed rate R,,,. = 7 The output data “A” is transmitted from the encoder before the 


output bit denoted as “B”. The functional flow is shown in Figure 22. Since there are six 
memory elements (constraint length v of 7) in the shift register, this explains the 


requirement of having six “‘zero” tail bits in the SIGNAL field prior to encoding. 





Output Data A 


Input Data 


Output Data B 


Figure 21. — convolutional encoder (v =7 ) (from: reference [3], Fig. 114). 
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Tx2.6: SIG_conv_enc 


F Tx2.6-I1: 
"/ — convEnc_input — 
Process data () — 
| 











Tx2: 
SIGNAL_map 






Input information 
bits 











WET 
SIG_interelaver 





ay Tx2.6-01: 
convEnc_output / 






Encoder 
polynomial 


Figure 22. $J/G_conv_enc port and functional flow. 


3. Tx2.7: Interleaver (SIG) 


Component name: S/G_interleaver 





Port design: $/G_interleaver has | input port and 1 output port. Figure 23 shows 





the I/O distribution of the component. 

Functional design: All data bits are passed through a block interleaver after the 
encoding process. The interleaver has a block size equals to the number of coded bits in a 
single OFDM symbol, N_,,, (see Table 9). The interleaver consists of two different 
permutations. The first permutation ensures that adjacent coded bits do not map onto 
adjacent subcarriers (refers to Equation 1 for the mapping). The second permutation 
ensures that adjacent coded bits are alternate between less and more significant bits after 
the mapping to prevent long runs of low reliability bits [3] (refers to Equation 2 for the 
mapping). Note that k, i and j refer to the index of the coded bit before the first, before 


the second and after the second permutation, respectively. The function floor(.) denotes 


the largest integer not exceeding the parameter. The value of s is derived from the 


: : . N 
number of coded bits per subcarrier, N,p.., according to s=max (Mase. Hence, 


s =1. The functional flow is shown in Figure 23. 
j=( Mewes }(kmod 16)+ foor| ike iesig ll ae] (1) 


i 





j= vestor( 2) Nan ~ oor 6% J} & £70 lnuNen Hl (2) 
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Tx2.7: SIG_interelaver 
Tx2.7-11: é ; 
Interleaver_input 1° permutation 
Process data () 2" permutation 





Tx2.6: Tx2.7-01: Tx2.8: 
SIG_conv_enc interleaver_outpu SIG_BPSK_mod 












Figure 23. $/G_interleaver port and functional flow. 


4. Tx2.8: BPSK Modulation (SIG) 
Component name: SIG_BPSK_mod 





Port design: S$1G_BPSK_mod has 1 input port and 1 output port. Figure 29 shows 
the I/O distribution of the component. 


Functional design: The SIGNAL OFDM subcarriers shall be modulated by using 





BPSK modulation. The encoded and interleaved binary input data shall be converted into 
complex BPSK constellation points. The output values for a modulator are formed by 
multiplying the resulting I and Q channel values by a normalization factor Kmop to 
achieve the same average power for all mappings. For BPSK modulation, Kyop 1s unity, 


and normalization is not necessary in this specific modulator. 





( Tx2.8: SIG_BPSK_mod ) 


| Tx2.8-I1: . Tx2.8-01: Tx2.9: 
BPSK mapping 4 mod_output SIG_carriers_map 
Process data () 


Figure 24. $/G_BPSK_mod port and functional flow. 








Tx2.7: 
SIG_interelaver 










Normalize 
(not needed for 
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5. Tx2.9: Carriers Mapping (SIG) 
Component name: S/G_carriers_map 


Port design: S/G_carriers_map has 1 input port and | output port. Figure 25 
shows the I/O distribution of the component. 
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Functional design: Four pilot tones are inserted to form 52 subcarriers. Similar to 
its preamble counterpart, S/G_carriers_map re-indexes this 52 subcarriers after BPSK 
modulation as part of the 64 frequency samples (by introducing guard bands as stipulated 
in the IEEBE standard) to serve as input into the IFFT component. The functional flow is 


shown in Figure 25. 





| Tx2.9: SIG_carrier_map 


Tx2.8: Tx2.9-11: insert vilckt 
SIG_BPSK_mod crMap_input nsert pilot tones 
Process data () | Re-index Tx2.9-01: 7 Tx2.10: 
for IFFT ; crMap_output SIG_IFFT 


Figure 25. | S$JG_carriers_map port and functional flow. 








6. Tx2.10: IFFT (SIG) 
Component name: SIG_IFFT 


Port design: S/G_IFFT has 1 input port and 1 output port. Figure 26 shows the I/O 


distribution of the component. 


Functional design: From S/G_carriers_map, 64 frequency samples will be sent 
through S/G_IFFT to convert to 64 time samples. The DIT PINO IFFT algorithm shall be 
described in Chapter V. The functional flow is shown in Figure 26. 


Tx2.10: SIG_IFFT 


Tx2.9: 2 : 
SIG_carriers_map 7 Bit reverssal 
, ] ] 
| Convert input to [iii DITPINO— | Tx2.10-01: Tx2.11: 
Process data() -——t>| complex (V/Q) freq ;-— IFFT IFFT_output ~-P) siG_cyclicPrefix 
samples | - = 


Figure 26. S/G_IFFT port and functional flow. 





7. Tx2.11: Cyclic Prefix (SIG) 
Component name: SIG_cyclicPrefix 


aD 


Port design: $/G_cyclicPrefix has | input port and 1 output port. Figure 27 shows 
the I/O distribution of the component. 


Functional design: S/G_cyclicPrefix prefixes a quarter of the length of the IFFT 





time samples to the data to form the SIGNAL subframe. This sequence shall be 
forwarded to SIGNAL_map to be concatenated as part of PPDU. The functional flow is 


shown in Figure 27. 


Tx2.11: SIG_cyclicPrefix 


a Tx2.11-11: 
cyPre_input 
hae | Shift input right aK Append | Tx2.11-01: | Tx2: 

Process data 0 a | by (IFFT_len/4) | (IFFT_len/4) nie cyPre_output | SIGNAL_map 


Tx2.10: | 
SIG_IFFT 









Figure 27. SIG_cyclicPrefix port and functional flow. 


C. DATA 

The DATA field contains the SERVICE field, the PSDU, the TAIL bits, and the 
PAD bits (when necessary). The SERVICE field has 16 bits as shown in Figure 28. The 
first 7 bits are set to zeros to synchronize the descrambler over at the receiver. The 
remaining 9 bits are reserved for future use and are also set to zero. The PSDU tail bit 
field shall be six bits of “0”, which serve the function of returning the convolutional 
encoder to the “zero state” (similar function as the 6 tail bits of SIGNAL field). The 
PPDU tail bit field shall be maintained by replacing six scrambled “zero” bits following 


the end of the message (which may not be “zero’”’) with six non-scrambled “zero” bits. 


Scrambler Initialization Reserved SERVICE Bits R: Reserved 
“0” “Oo” “Oo” “Oo” “Oo” “Oo” “O77 R R RRRRRRR 





Transmit Order 


Figure 28. | Composition of SERVICE field (from: reference [3], Fig. 112). 
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Besides all the components (functionalities) under the SIGNAL subframe, 
forming the DATA subframe requires an additional initial procedure of scrambling the 


information. Table 10 summarizes the components needed to form the DATA subframe. 






































Index Component Functions 

Tx3 data_map - form time data samples from PSDU 
- send DATA samples to form PPDU 

Tx3.4 data_scrambler - scramble the raw data 

Tx3.5 data_tail_replacement | - replace tail with zero 

Tx3.6 data_conv_enc - data convolutional encoding 
- data puncturing 

TxX3.7 data_interleaver - data interleaving 

Tx3.8 data_mod_map - data modulation mapping 

Tx3.9 data_carriers_map - data carriers mapping 

Tx3.10 data_IFFT - data IFFT 

Tx3.11 data_cyclicprefix - data cyclic prefix 

Tx0 idata_PSDU - input PSDU data 














Table 10. TEEE 802.11a Transmitter DATA subframe components functionalities. 


1. Tx3: DATA Mapping 
Component name: DATA_map 





Port design: DATA_map has a total of 3 input ports and 3 output ports. Figure 29 


shows the I/O distribution of the component. 


Tx3: DATA_map 
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Figure 29. | DATA_map port and functional flow. 
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Tx12: 
PPDU_map 





Functional design: DATA_map is the heart of DATA processing at the PHY layer 
where PSDUs from the MAC layer are processed into time samples to be concatenated 
and formed the PPDU. The first function in this component is to extract important 


information from the two control fields: RATE and LENGTH. From RATE (data 


af 


transmission rate), the modulation type and coding parameters are defined as shown in 


















































Table 11. 
Data rate Modulation Coding rate Coded bits Coded bits Data bits 
(Mbits/s) (R) Per per OFDM per OFDM 
subcarrier symbol symbol 
(WN esa) (Noses ) (Nes ) 
6 BPSK 1/2 1 48 24 
9 BPSK 3/4 1 48 36 
12 QPSK 1/2 2 96 48 
18 QPSK 3/4 2 96 72 
24 16-QAM 1/2 4 192 96 
36 16-QAM 3/4 4 192 144 
48 64-QAM 2/3 6 288 192 
54 64-QAM 3/4 6 288 216 
Table 11. Rate-dependent parameters. 


The LENGTH field determines the size of PSDU to be sent in a PPDU frame, 
which is user dependent. The length of the message is extended to be a multiple of 
N ppps > While ensuring the number of bits in the DATA field is a multiple of N.,,,. This 
is possible by inserting PAD bits to the PPDU frame. The number of OFDM symbols, 
Nyy» the number of bits in the DATA field, N,,,,, and the number of PAD bits, N,,,, 


are computed according to Equation 3, 4 and 5 respectively. 


Neyy = ceiling ((16 + 8 x LENGTH + 6)/Nppps) (3) 
Noara = Novw X Nogps (4) 
Noap = Noara - (16 + 8 X LENGTH + 6) (5) 


The ceiling(.) function returns the smallest integer value greater than or equal to 
its argument value. The appended PAD bits are set to “zero” and shall be scrambled with 


the other bits in the DATA field. 


From the LENGTH field, DATA_map carries out its second function of retrieving 
the PSDU from the MAC layer (simulated by DATA_PSDU). After that, the DATA bits 
are sent for processing into time samples. The OFDM symbols are transferred to 


PPDU_map and form the PPDU. The functional flow is shown in Figure 29. 
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2; Tx3.4: Scrambler (DATA) 


Component name: DATA_scrambler 





Port design: DATA_scrambler has 1 input port and | output port. Figure 31 shows 
the I/O distribution of the component. 


Functional design: The DATA subframe shall be scrambled with a length-127 
scrambler stipulated in the IEEE 802.11a standard (as illustrated in Figure 30). The 
scrambler is set to a pseudo random non-zero initial state when first applied to the input 


data. This initial state must be the same as that for the receiver descrambler. The 
functional flow is shown in Figure 31. X' to X’ represent the seven shift registers and 


the outputs from the fourth (x " and seventh (x ) registers are mod-2 added and 


cycled back to the shift registers. This mod-2 output is also used to scramble the input 


data by mod-2 addition with the input data. 


Data In 





Data Out 


Figure 30. | DATA scrambler (from: reference [3], Fig. 113). 


Tx3.4: DATA_scrambler 








: oa Tx3.441: 
Tx3: DATA_map ---}-- scrambler_input >_> | raw DATA i] 
7 \ ; Tx3.4-01: 
' / "/ scrambler_output 
Process data () generator 
: : polynomial 


Figure 31. | DATA_ scrambler port and functional flow. 













dixo:5: 
DATA _tail_replace 





3: Tx3.5: Tail Replacement (DATA) 
Component name: DATA_tail_replacement 


Port design: DATA_tail_replacement has | input port and 1 output port. Figure 32 


shows the I/O distribution of the component. 
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Functional design: The DATA tail bit field shall be reproduced by replacing six 
scrambled “zero” bits following the message end with six non-scrambled “zero” bits. The 
six “zero” tail bits are needed to return the convolution encoder (next component) to the 


state of all “zero”. The functional flow is shown in Figure 32. 





( Tx3.5: DATA_tail_replace 
Process data () ».| Extract pointer to ,|Re-insert ‘zero’ into Tx3.5-01: | E Tx3.6: 
: ; TAIL bits = TAIL bits | tail_output a | DATA_conv_enc 


Figure 32. | DATA_ tail_replacement port and functional flow. 
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4. Tx3.6: Convolutional Encoder (DATA) 


Component name: DATA_conv_enc 





Port design: DATA_conv_enc has 1 input port and | output port. Figure 34 shows 


the I/O distribution of the component. 
Functional design: The DATA subframe shall be coded with a convolutional 


encoder of coding rate R= 7 >. or , depending on the data rate being transmitted 


(see Table 11). The convolutional encoder is shown in Figure 21 with the two generator 


polynomials stated in the IEEE 802.11a standard (g, =133, and g, =171,) and a fixed 


1 
rate R,, = The bit denoted as “A” is transmitted from the encoder before the bit 


denoted as “B”. The process of puncturing is employed to obtain the higher coding rates. 


Puncturing is a procedure for removing some of the encoded bits in the transmitter after 


passing through the R,,. => generator polynomials. The puncturing patterns are 


illustrated in Figure 33 for R => and ~. Note that no puncturing is needed for R= 7 


The functional flow of the component is shown in Figure 34. 
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Puncturing code: R=3/4 



































Source bits xO | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 
Encoded bits AO | At A3 | A4 A6 | A7 
BO B2 | B3 B5 | B6 B8 
Transmitted bits AO | BO | A1 | B2 | A3 | B3 | A4 | B5 | A6 | B6 | A7 | B8 












































Puncturing code: R=2/3 



































Source bits xO | x1 | x2 | x3 | x4 | x5 | x6 | x7 | x8 | x9 
Encoded bits AO | A1 | A2 | A3 | A4 | A5 | A6 | A7 | A8 | AQ 
BO B2 B4 B6 B8 
Transmitted bits AO | BO | Ail | A2 | B2 | A3 | A4 | B4 | A5 | A6 | B6 | A7 | A8 | B8 | AQ 


















































i punctured bit 


Figure 33. © DATA_conv_enc puncturing patterns (after: reference [3], Fig. 115). 
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Figure 34. | DATA_conv_enc port and functional flow. 
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5, Tx3.7: Interleaver (DATA) 
Component name: DATA_interleaver 


Port design: DATA_interleaver has 1 input port and 1 output port. Figure 35 


shows the I/O distribution of the component. 


Functional design: All data bits are passed through a block interleaver after the 





encoding process. The interleaver has a block size equals to the number of coded bits in a 


single OFDM symbol, N_,,, (see Table 11). The interleaver consists of two different 


permutations as described in Section B3. The value of s is derived from the number of 
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Tx3.7: 
DATA_interelaver 















. : : N ; 
coded bits per subcarrier, N,p.-, according to s= max 5 SC a. Note that this process 


is carried out for Nzgiocx (Nyy ) iterations. The functional flow is shown in Figure 35. 





| 1x3.7: caramel | 


TUS 1x8.7-11: Determine - ; 
DATA_conv_enc | Interleaver_input 1° permutation 
iterate 

Nevock | 
Process data —! nd : Tx3.7-01: 
: = RAMON interleaver_outpu 
Tx3.8: 
DATA_mod_map 























times 


Figure 35. § DATA_interleaver port and functional flow. 


6. Tx3.8: Modulation Mapping (DATA) 
Component name: DATA_mod_map 


Port design: DATA_mod_map has | input port and | output port. Figure 37 shows 


the I/O distribution of the component. 


Functional design: The DATA OFDM subcarriers is modulated by either BPSK, 
QPSK, 16-QAM, or 64-QAM modulation, depending on the RATE field. The input 
binary data shall be converted into complex constellation points as shown in Figure 36. 
The output values are formed by multiplying the resulting complex value by a 


normalization factor Kyo, (see Table 12) to achieve the same average power for all 


mappings. The functional flow is shown in Figure 37. 

















Modulation Kyop 
BPSK 1 
QPSK 1/V2 
16 QAM 1/V10 
64 QAM 1/V42 














Table 12. Normalization factor (after: reference [3], Table 81). 
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Input bits 
|- 3 
(bo) out Q-out 
0 =] 0 
BPSK 
1 1 0 
Input bits : Input bits ' Input bits I. Input bits : 
(bo) i a ne (bobrsbe) | TU | (oa,basbs) | POU 
0 -1 0 -1 000 -7 000 -7 
QPSK 
1 1 1 1 001 -5 001 -5 
011 -3 011 -3 
Input bits Input bits 
l-out Q-out 010 -1 010 -1 
(1,1) (b2,bs) 64 QAM 
00 -3 00 -3 110 1 110 1 
01 -1 01 -1 111 3 111 3 
16 QAM 

11 1 11 1 101 5 101 5 
10 3 10 3 100 7 100 7 


























Figure 36. Constellation modulation mapping (after: reference [3], Table 82 to 85). 
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Figure 37. | DATA_mod_map port and functional flow. 


Ve Tx3.9: Carriers Mapping (DATA) 
Component name: DATA_carrier_map 


Port design: DATA_carrier_map has 1 input port and | output port. Figure 38 


shows the I/O distribution of the component. 


Functional design: Four pilot tones are inserted to form 52 subcarriers. Similar to 





its SIGNAL counterpart, DATA_carrier_map re-indexes the 52 subcarriers after 
modulation as part of the 64 frequency samples (by introducing guard bands as stipulated 
in the IEEE standard) to serve as input into the IFFT component. Note that this process is 


carried out for N,,,, iterations. The functional flow is shown in Figure 38. 
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(nee: DATA. caters a | 


Tx3.9-11: Insert pilot tones 
| crMap_input 
| Reindex | _ Tx3.9-01: ; 1x3.10: 
Process data () | for IFFT [7 crMap_output DATA_IFFT 


Figure 38. © DATA_carriers_map port and functional flow. 
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DATA_mod_map 

















iterate 
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times 







8. Tx3.10: IFFT (DATA) 
Component name: DATA_IF FT 


Port design: DATA_IFFT has 1 input port and 1 output port. Figure 39 shows the 


I/O distribution of the component. 


Functional design: From DATA_carriers_map, 64 frequency samples will be sent 
through DATA_IFFT to convert to 64 time samples. The DIT PINO IFFT algorithm shall 


be described in Chapter V. Note that this process is carried out for N,,,, iterations. The 


functional flow is shown in Figure 39. 


Tx3.10: DATA_IFFT 
Tx3.9: 
DATA _carriers map | | 










| Tx3.10-11: 
IFFT_input pl 
Process data () 


| Tx3.10-01: 
| Bit reverssal IFFT_output 


Figure 39. DATA_IFFT port and functional flow. 
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times 















| Convert input to 
| complex (I/Q) freq 
| samples 


Tx3.11: 
“| DATA _cyclicPrefix 






9, Tx3.11: Cyclic Prefix (DATA) 
Component name: DATA_cyclicPrefix 


Port design: DATA_cyclicPrefix has 1 input port and | output port. Figure 40 


shows the I/O distribution of the component. 


Functional design: DATA_cyclicPrefix prefixes a quarter of the length of the 





IFFT time samples to the data to form the DATA subframe. Note that this process is 
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carried out for N,,,, iterations. The final sequence shall be forwarded to DATA_map to 


be concatenated as part of the PPDU. The functional flow is shown in Figure 40. 


Tx3.11: DATA_cyclicPrefix 
Tx3.10: | 133.1141: Agnes 
DATA_IFFT cyPre_input A P New 
! times / 
ine | Shift input right at | Append i ; Tx3.11-01: . Tx3: 
Process date () | by (IFFT_len/4) | = teeta prefix >  cyPre_output > DATA map 





Figure 40. | DATA_cyclicPrefix port and functional flow. 


D. PPDU (FINAL CONCATENATION) 

The final piece to the transmitter is the function of concatenating the preamble, 
SIGNAL and DATA subframes together and form the PPDU frame. This main control is 
carried out by the PPDU_map component. 


1. Tx12: PPDU Mapping 
Component name: PPDU_map 


Port design: PPDU_map has a total of 3 input ports and 3 output ports. Figure 41 


shows the I/O distribution of the component. 


Functional design: As mentioned, PPDU_map is the final component that 





concatenates all the three subframes. It carries out three main functions: (1) retrieves 
preamble subframe from preamble_map component, (2) initiate SIGNAL processing and 
storage and (3) initiate DATA processing and storage. The final PPDU frame is ready to 
be sent for hardware DAC and RF up-conversion to the 5GHz range before transmission 


as stipulated in the IEEE 802.11a standard. The functional flow is shown in Figure 41. 
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Tx12: PPDU_map 
Tx12-11: 
preamble_input 
Concatenate 
Process data () , Call SIGNAL Store SIGNAL Call DATA Store DATA Preamble, SIGNAL 
processing sequence processing sequence 
& DATA 
Store preamble Tx12-01: Tx12-O2: ; Tx12-13: Tx12-O03: 
Sequence SIG_processing DATA_processing DATA_Input PPDU frame 
: Tx2: 7 i Tx3: ss Hardware 
SIGNAL_map DATA_map transmission 


Figure 41. © PPDU_map port and functional flow. 


Txt: 
preamble_map 















In this chapter, the developmental details of the transmitter to model the IEEE 
802.1la PHY layer have been described. The transmitter components consist of the 
preamble, SIGNAL and DATA subframes. These three subframes are concatenated 
subsequently to from the PPDU frame. In the next chapter, we shall focus on describing 


the developmental details for the receiver components. 


46 






IV. DEVELOP: RECEIVER 


This chapter focuses on the receiver portion of the IEEE 802.11a PHY layer. Like 
before, the components are described according to the inter-linkages of the input-output 


(I/O) ports and the functional implementation in C++ code. 


The receiver converts the digitized PPDU frames (passed down from the ADC 
after down-conversion from the RF front end) into binary outputs from which the original 
PSDU information can be extracted. The incremental development is discussed here 
starting with the removal of the preamble subframe, follow by the SIGNAL subframe, 
and finally, the DATA subframe where the PSDU is extracted. 


A. PREAMBLE 

In this subframe, the two core tasks are to receive the digitized time samples and 
remove the preamble subframe prior further processing. The preamble subframe consists 
of training sequences, which are predictable such that it can be tracked and removed from 
the received data. Table 13 summarizes the components needed to remove the preamble 


subframe from the received data. 











Index Component Functions 
Rx0 Rx_data - receive digitized data stream 
Rx1/Rx12 PPDU_rx - extract the required digitized PPDU stream 


- removed preamble from PPDU 
- send stream for SIG removal 














Table 13. TEEE 802.11a Receiver preamble subframe components functionalities. 


i, Rx0: Receiver Data (Assembly Controller) 
Component name: Rx_data 


Port design: Rx_data is the assembly controller for the receiver. It initiates the 





receiver software routine to extract the PSDU frame. It has one output port that sends 
continuous digitized time samples to PPDU_rx component. Figure 42 shows the I/O 


distribution of the component. 
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: ADC 
FRRGE Ii Gb ii | (Hardware receiver) 


Start () 













| Initiate Rx routine 


Process data () 


Retrieve digitized Send digitized Rx0-01: | 
samples samples Rx_output 


Figure 42. Rx_data port and functional flow. 


Functional design: Rx_data emulates the ADC interface at the receiver by sending 





digitized samples for software processing. For testing purposes, the test data provided in 
Annex G of IEEE 802.11a standard [3] shall be sent out from Rx_data one sample at a 
time. It will be followed by a stream of ‘zero’ until it reaches the upper limit assumed in 


the simulation. This sequential functional flow is shown in Figure 42. 


2. Rx1: PPDU Receiver 


Component name: PPDU_rx 





Port design: PPDU_rx has a total of 1 input port and 1 output port. Figure 43 


shows the I/O distribution of the component. 


Rx1: PPDU_rx 








Rx1-I1: ‘zeros’? 
: Rx1-01: 
PPDU_rx_input PPDU_rx_output 


Preamble 


Rx2: 
SIGNAL_rx 





reference 
- 5 it | 
Process data () 1 has a 
| 
| : | Remove Preamble Send Preamble- 
No | subframe removed sequence 
| 


Figure 43. © PPDU_rx port and functional flow. 


Functional design: PPDU_rx carries out three main functions: (1) receive the 





digitized time samples, (2) remove preamble subframe, and (3) send the processed data 
stream for SIGNAL subframe processing. For synchronization, the digitized samples are 
continually received until the component senses a continuous stream of ‘zeros’ 
(determine by nsCount). This indicates all the digitized samples have been received. The 
received data stream is compared with the preamble training sequence (a concatenation of 


ST and LT sequences) that is specified in the IEEE 802.11a standard [3] and, therefore, 
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known in advance, and the remaining (SIGNAL + DATA) subframes are extracted. The 


functional flow is shown in Figure 43. 


B. SIGNAL 
The SIGNAL symbol consists of the critical RATE and LENGTH fields that are 


encoded by a convolutional code of R=>. In order to remove this subframe, the 


functionalities described in the equivalent transmitter subframe shall be reversed to 
extract the two critical fields. The decoding of the SIGNAL field into an OFDM symbol 
follows the procedures: removing the cyclic prefix, FFT, removing the pilot tones (guard 
bands), BPSK demodulation, deinterleaving and, finally, convolutional decoding at a data 
receiver rate of 6 Mbits/s. Table 14 summarizes the components needed to extract the 


necessary fields. 








Index Component Functions 
Rx2 Header_rx - removed SIG from PPDU 
(SIGNAL_ rx) - send SIG for processing 


- extract RATE & LENGTH from SIG 
- send received data for processing 
































Rx2.11 SIG_cyclicprefix_rem - SIG cyclic prefix removal 
Rx2.10 SIG_FFT - SIG FFT 

Rx2.9 SIG_carriers_demap - SIG carriers demapping 
Rx2.8 SIG_BPSK_demod - SIG BPSK demodulation 
Rx2.7 SIG_deinterleaver - SIG deinterleaving 

Rx2.6 SIG_conv_dec - SIG convolutional decoding 





Table 14. IEEE 802.11a Receiver SIGNAL subframe components functionalities. 


1. Rx2: SIGNAL Receiver 
Component name: SIGNAL_rx 


Port design: SIGNAL_rx has a total of 2 input ports and 2 output ports. Figure 44 


shows the I/O distribution of the component. 


Functional design: SJGNAL_rx carries out the function of extracting important 
parameters (RATE and LENGTH) and sends them for DATA processing together with 
the DATA subframe. At a data rate of 6 Mbits/s, the modulation type and coding 


parameters are fixed as shown in Table 15. The functional flow is shown in Figure 44. 
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Data rate Modulation Coding rate Coded bits Coded bits Data bits 
Mbit. R Per per OFDM per OFDM 
( ; a) s) ( ) subcarrier symbol symbol 
CN nests) (Nese ) UN pass ) 
6 BPSK 1/2 1 48 24 
Table 15. | Rate-dependent parameters: 6 Mbits/s. 


Rx1: 
PPDU_rx 





2. 






Rx2: SIGNAL_rx 
_»| Extract SIGNAL : Call SIG Store RATE & ; 
: subframe processing LENGTH 


Rx2-O1: Rx2-12: F Rx2-02: 
SIG_process_outpu SIG_process_input ; SIG_rx_output 
; ( 


Process data () 


Figure 44. 





Y 





| SIG_cyclicPrefix_re 


Rx2.11: 


Rx2.6: 


SIG_conv_dec 





SIGNAL_rx port and functional flow. 


Rx2.11: Cyclic Prefix Removal (SIG) 














Component name: S1G_cyclicPrefix_rem 


Port design: S7G_cyclicPrefix_rem has a total of 1 input port and 1 output port. 
Figure 45 shows the I/O distribution of the component. 





Functional design: S/G_cyclicPrefix_rem removes the prefixes (a quarter of the 
length of the IFFT time samples) from the input data to retrieve the original time samples 
obtained from the transmitter IFFT. This sequence shall be forwarded to S/G_FFT for the 
FFT. The functional flow is shown in Figure 45. 





Rx2.11: SIG_cyclicPrefix_rem 
Rx2: a | Rx2.11-11: 
SIGNAL_rx | ©/ cyPre_rem_input 
Process data () Mark end of i Remove the Rx2.11-O1: A q Rx2.10: 
cyclic prefix : cyclic prefix cyPre_rem_outpu' | SIG_FFT 


SIG_cyclicPrefix_rem port and functional flow. 





Figure 45. 
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3. Rx2.10: FFT (SIG) 
Component name: SIG_FFT 


Port design: S1G_FFT has | input port and 1 output port. Figure 46 shows the I/O 


distribution of the component. 


Functional design: From S/G_cyclicPrefix_rem, 64 time samples will be sent 


through SJG_FFT to convert to 64 frequency samples. The DIT PINO FFT algorithm 





shall be described in Chapter V. The functional flow is shown in Figure 46. 


Rx2.10: SIG_FFT 
Rx2.11: _ ee Rx2.10-11: . 
SIG_cyclicPrefix_rem ; FFT_input Bit reverssal 
. oe ee DIT PINO Rx2.10-O1: i 1 Rx2.9: 
Process data () : ape ined req FFT FFT_output SIG_carriers_demap 


Figure 46. S/G_FFT port and functional flow. 





4. Rx2.9: Carriers Demapper (SIG) 
Component name: S1G_carriers_demap 


Port design: S/G_carriers_demap has 1 input port and 1 output port. Figure 47 


shows the I/O distribution of the component. 


Functional design: S/G_carriers_demap re-indexes the 64 frequency samples (by 
removing guard bands as stipulated in the IEEE standard) and retrieves the 52 
subcarriers. Four pilot tones are removed before passing the data stream for BPSK 


demodulation. The functional flow is shown in Figure 47. 


cc 9 cris demap | 
; ] 
Rx2.10: Rx2.9-I1: Re-index 
SIG_FFT crDemap_input for BPSK demod 
Ee L | 
P d Remove : Rx2.9-01: | . Rx2.8: 
rocess data () -— pilot tones *7 crDemap_output SIG_BPSK_demod 


Figure 47. S/G_carriers_demap port and functional flow. 
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a. Rx2.8: BPSK Demodulator (SIG) 
Component name: $1G_BPSK_demod 





Port design: SJG_BPSK demod has | input port and 1 output port. Figure 48 





shows the I/O distribution of the component. 


Functional design: The SIGNAL bits are retrieved by using BPSK demodulation. 
The 48 frequency subcarriers are demodulated to retrieve the encoded and interleaved 


binary data, taking into consideration the normalization factor, Kyo pj (see Table 12). For 


BPSK demodulation, Kyo, is unity. The functional flow is shown in Figure 48. 





| Rx2.8: (ees) 
Rx2.8-11: BPSK demod Rx2.8-01: Rx2.7: 
demod_input mapping demod Lael SIG_deinterleaver 
Normali 
Process data ta () i keaese aoe) 


Figure 48. | S/G_BPSK demod port and functional flow. 








Rx2.9: 
SIG_carriers_demap 















6. Rx2.7: De-Interleaver (SIG) 
Component name: S1G_deinterleaver 


Port design: S/G_deinterleaver has | input port and 1 output port. Figure 49 





shows the I/O distribution of the component. 


Functional design: All data bits are passed through a block deinterleaver after 
demodulation. The deinterleaver has a block size equals to the number of coded bits in a 


single OFDM symbol, N.,,, (see Table 15). The deinterleaver consists of two different 


permutations, which is the inverse of the transmitter interleaver described in Chapter III. 


Note that j, 7 and k refer to the index of the coded bit before the first, before the second 
and after the second permutation, respectively. Note that s = max (Mase. Equation 6 


and 7 respectively describe the first and second permutations. 





i=s « floor{ 2 (i + floor(16 x ma |. i, j,k =0,1,...,Nepps-l (6) 
Ss 


CBPS 


32 





k = 16 Xi - (Negps - 1) floor(6 x 


Rx2.7-11: 4 : 
delnterleaver_input 1° permutation 
nd a 
Process data () 2™ permutation 


Figure 49. $/G_deinterleaver port and functional flow. 
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CBPS 





Rx2.8: Rx2.7-O1: Rx2.6: 
SIG_BPSK_demod deinterleaver_output SIG_conv_dec 














7. Rx2.6: Convolutional Decoder (SIG) 


Component name: SIG_conv_dec 





Port design: $JG_conv_dec has 1 input port and | output port. Figure 50 shows 


the I/O distribution of the component. 


Functional design: Viterbi decoding is chosen to decode the stream of 





convolutional bits. Since the SIGNAL fields have been coded with a convolutional 
; 1 . : : . ; 
encoder of coding rate R =. there is no need to insert dummy bits prior decoding. 


Details of the Viterbi decoder algorithm are presented in Chapter V. The functional flow 


is shown in Figure 50. 


Rx2.6: SIG_conv_dec 


Rx2.7: 
SIG_deinterleaver 


Rx2.6-I1: j 1 
r . : . . Rx2.6-O1: Rx2: 
eee "/ convdec_output SIGNAL_x 
Process data 
initialise_viterbi() 


process_viterbi() 





Figure 50. S7G_conv_dec port and functional flow. 


ihe: 


C. DATA 


Besides all the components (functionalities) under the SIGNAL subframe, 
extracting the PSDU from the DATA subframe requires an additional procedure of 
descrambling the decoded bits. Table 16 summarizes the components needed to extract 


the PSDU. 









































Index Component Functions 
Rx3 data_rx - receive and send raw data for processing 
- receive and send PSDU data to MAC layer 
Rx3.11 data_cyclicprefix_rem | - data cyclic prefix removal 
Rx3.10 data_FFT - data FFT 
Rx3.9 data_carriers demap - data carriers demapping 
Rx3.8 data_demod_map - data demodulation mapping 
Rx3.7 data_deinterleaver - data deinterleaving 
Rx3.6 data_conv_dec - data dummy insertion 
- data convolutional decoding 
Rx3.5 data_tail_replace - not required, encompass in descrambler 
Rx3.4 data_descrambler - descramble the raw data 








Table 16. IEEE 802.11a Receiver DATA subframe components functionalities. 


1. Rx3: DATA Receiver 


Component name: DATA_rx 





Port design: DATA_rx has a total of 2 input ports and 2 output ports. Figure 51 


shows the I/O distribution of the component. 


Functional design: DATA_rx is the heart of DATA processing at the PHY layer 





where the PSDU are extracted. This is possible by referencing information provided by 
RATE and LENGTH fields. From RATE, the modulation type and coding parameters are 
determined according to Table 17. The LENGTH field determines the size of PSDU in 
the DATA. The functional flow is shown in Figure 51. 
































Data rate | Modulation | Coding | Coded bits per Coded bits per Data bits per 
( Mbits / 5 ) rate subcarrier OFDM symbol OFDM symbol 
(R) (Nae) (Neuss) (N onas) 

6 BPSK 1/2 1 48 24 

9 BPSK 3/4 1 48 36 

12 QPSK 1/2 2 96 48 

18 QPSK 3/4 2 96 72 

24 16-QAM 1/2 4 192 96 

36 16-QAM 3/4 4 192 144 

48 64-QAM 2/3 6 288 192 

54 64-QAM 3/4 6 288 216 




















Table 17. | Rate-dependent parameters. 
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Rx3: DATA_rx 
Rx2: Rx3-I1: 
SIGNAL_rx DATA_rx_input 
Process data () Call DATA Store PSDU 
processing sequence 


Process control Rx3-01: Rx3-l2: Rx3-O2: 
fields: DATA_processing DATA_processing DATA_rx 


RATE, LENGTH input output output 





Yv 
Rx3.11: Rx3.4: Rx3.0: 
DATA _cyclicPrefix_rem DATA_descrambler DATA_rx_PSDU 


Figure 51. © DATA_map port and functional flow. 








2. Rx3.11: Cyclic Prefix Removal (DATA) 
Component name: DATA_cyclicPrefix_rem 


Port design: DATA_cyclicPrefix_rem has a total of 1 input port and | output port. 
Figure 52 shows the I/O distribution of the component. 


Functional design: DATA_cyclicPrefix_rem removes the prefixes (a quarter of the 





length of the IFFT time samples) from the input data to retrieve the original time samples 
obtained from the transmitter IFFT. Note that this process is carried out for Nyy 


iterations. This sequence shall be forwarded to DATA_FFT component for the FFT. The 


functional flow is shown in Figure 52. 





Rx3.11: DATA_cyclicPrefix_rem | 


Rx3.11-I1: 
cyPre_rem_input : 
i Mark end of P Remove the Rx3.11-O1: é 
Process data () ; cyclic prefix cyclic prefix cyPre_rem_outpul 


Figure 52. DA TA_cyclicPrefix_rem port and functional flow. 
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3. Rx3.10: FFT (DATA) 
Component name: DATA_ FFT 


Port design: DATA_FFT has 1 input port and 1 output port. Figure 53 shows the 


I/O distribution of the component. 


Functional design: From DATA_ cyclicPrefix_rem, every 64 time samples will be 


sent through DATA_FFT to convert to 64 frequency samples. The DIT PINO FFT 





algorithm shall be described under Chapter V. Note that this process is carried out for 


Nyy iterations. The functional flow is shown in Figure 53. 


Rx3.10: DATA_FFT 
Rx3.10-11: 
FFT_input 
“Convert input to Rx3.10-O1: 
Process data () complex (I/Q) freq i = FFT_output " 
samples ~ 


Figure 53. © DATA_FFT port and functional flow. 






rate 


Rx3.11: - 
DATA _cyclicPrefix_rem 





















= Rx3.9: 
| DATA_carriers_demap 


4. Rx3.9: Carriers Demapper (DATA) 


Component name: DATA_carriers_demap 





Port design: DATA_carriers_demap has | input port and | output port. Figure 54 


shows the I/O distribution of the component. 


Functional design: © DATA_carriers_demap re-indexes every 64 frequency 





samples (by removing guard bands) and retrieves the 52 subcarriers. Four pilot tones are 


also removed for demodulation mapping. Note that this process is carried out for Nyy 


iterations. The functional flow is shown in Figure 54. 





| Rx3.9: DATA_carriers_demap | 


Rx3.10: oe Rx3.9-11: Re-index 
DATA_FFT crDemap_input | for demod 
iterate 7 


Nsym 
times 


Process data () 5 
_- Remove Rx3.9-O1: = Rx3.8: 
pilot tones : crDemap_output DATA_demod_map 


Figure 54. DA cE port and functional flow. 
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Ds 
Component name: DATA_demod_map 


Rx3.8: Demodulation Mapper (DATA) 


Port design: DATA_demod_map has 1 input port and 1 output port. Figure 56 


shows the I/O distribution of the component. 


Functional design: 


The DATA OFDM subcarriers are demodulated by using 
BPSK, QPSK, 16-QAM, or 64-QAM, depending on the RATE field. The gray-coded 


complex constellation points shall be converted to binary input data according to Figure 


55. Note that the normalization factor K,,o, (see Table 12) changes with modulation 


scheme to ensure the same average power is achieved for all mappings. The functional 


flow is shown in Figure 56. 





































































































§ Output bits 
l-in (bs) 

-1 0 

BPSK 

1 1 

F Output bits F Output bits F Output bits er Output bits 
l-in (bo) Q-in (b:) I-in (bo,b1,b.) Qin (bs, ba,bs) 
-1 0 -1 0 7 000 7 000 

QPSK 
1 1 1 1 5 001 -5 001 
3 011 -3 011 

: Output bits : Output bits 

l-in Q-in 1 010 -1 010 
(0,1) (b2,bs) 64 QAM 
-3 00 -3 00 1 110 1 110 
-1 01 -1 01 3 111 3 111 
16 QAM 
1 11 1 11 5 101 5 101 
3 10 3 10 7 100 7 100 
Figure 55. Constellation demodulation mapping. 
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DATA_demod_map port and functional flow. 
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6. Rx3.7: De-Interleaver (DATA) 


Component name: DATA_deinterleaver 





Port design: DATA_deinterleaver has | input port and 1 output port. Figure 57 


shows the I/O distribution of the component. 


Functional design: All data bits are passed through a block deinterleaver after 
demodulation. The deinterleaver has a block size equals to the number of coded bits in a 


single OFDM symbol, N.,,, (see Table 17). The deinterleaver consists of two different 


permutations as described in Section B6. The value s is determined by the number of 





coded bits per subcarrier, N,ps-, whereby s = max Man a. Note that this process is 


carried out for Ng ocx (Nsyy ) iterations. The functional flow is shown in Figure 57. 
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Figure 57. § DATA_deinterleaver port and functional flow. 
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da Rx3.6: Convolutional Decoder (DATA) 
Component name: DATA_conv_dec 


Port design: DATA_conv_dec has 1 input port and | output port. Figure 59 shows 
the I/O distribution of the component. 


Functional design: Viterbi decoding is chosen to decode the stream of 





convolutional bits. The DATA bits have been coded with a convolutional encoder of 


1 2 : : 
coding rate R = 3 or , depending on the data rate (see Table 17). Since higher 


2 1 : . 
rates of R=— and 2 are derived from R = by employing puncturing at the 


transmitter, conversely, at the receiver, dummy bits have to be inserted prior to the 
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; ; ; ; 1 
decoding. There is no need to insert dummy bits prior to decoding for R =a The 


2 
dummy bits insertion patterns are illustrated in Figure 58 for R= 3 and ~. 


Details of 


the Viterbi decoder algorithm is presented in Chapter V. Note that process_viterbi() 


process call is carried out for N,,,, iterations. The functional flow is shown in Figure 59. 


Insertion pattern: R=3/4 






































































































































Received bits AO | BO | A1 | B2 | A3 | B3 | A4 | B5 | A6 | B6 | AZ | B8 
Dummy bits AO | Al A3 | A4 A6 | A7 

BO B2 | B3 B5 | B6 B8 
Decoded data yO | y1 | y2 | y3 | y4 | y5 | y6 | y7 | y8 

Insertion pattern: R=2/3 

Received bits AO | BO | Al | A2 | B2 | A3 | A4 | B4 | A5 | AG | BE | AZ | A8 | B8 | AY 
Dummy bits AO | Al | A2 | A3 | A4 | A5 | A6 | AZ | A8 | AQ 

BO B2 B4 B6 Bs [iBol 
Decoded data yO | y1 | y2 | y3 | y4 | y5 | y6 | y7 | y8 | y9 

Figure 58. | DATA_conv_dec puncturing patterns. 
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R=3/4 


Insert dummy : 
|‘zero’ appropriately 


Viterbi decoding 


iterate 
Nsym 
times 


Rx3.6-O1: 
initialise_viterbi() convdec_output 


process_viterbi() 


DATA_conv_dec port and functional flow. 
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Rx3.4: 
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8. Rx3.5: Tail Replacement (DATA) 


This function is subsumed under the descrambler component below. 


9. Rx3.4: Descrambler (DATA) 


Component name: DATA_descrambler 





Port design: DATA_descrambler has 1 input port and 1 output port. Figure 61 


shows the I/O distribution of the component. 


Functional design: The DATA subframe shall be descrambled by passing through 





the same length-127 scrambler as illustrated in Figure 60. The scrambler is set to a 
pseudo random non-zero initial state when first applied to the input data. This must be the 
same as that being used in the transmitter scrambler to ensure the descrambling process is 
synchronized. For the simulation and testing in this thesis research, this pseudo-random 
non-zero state has been set to “1011101” as proposed in the test case under Annex G of 


TEEE 802.11a standard [3]. The functional flow is shown in Figure 61. 


Data In 





Data Out 


Figure 60. © DATA scrambler. 
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Figure 61. © DATA_descrambler port and functional flow. 
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With an appreciation of the development of the transceiver, the next chapter shall 
proceed to touch on the challenges that were experienced during the conduct of the thesis 


research. 
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V. CHALLENGES 


This chapter focuses on the major challenges that were encountered while 
developing the IEEE 802.lla PHY layer model. In terms of developing the 
functionalities, two complex functions are singled out specifically for discussion. They 
are the (inverse) fast Fourier transform (IFFT/FFT) and the Viterbi decoder as described 
in Section A below. Being developmental software, OSSIE is still considered in its early 
stage of maturity. While the current version is useful and sufficient for modeling the 
standard, enhancement will definitely help in fine-tuning and optimizing the performance 


of the model. These software and integration challenges are discussed in Section B. 


A. SPECIAL INTEREST COMPONENTS 

The FFT and IFFT are software algorithms for (inverse) discrete Fourier 
transform (DFT/IDFT) that are used to emulate the OFDM capabilities in the standard. 
OFDM advocates parallel data transmission scheme that reduces the effect of multipath 
fading and prevent the need of complex equalizers at the receiver. The mathematical 
details can be obtained from reference [6]. For convolutional decoding, the Viterbi 
algorithm is recommended by the IEEE 802.11la standard [3]. Using the concept of a 
trellis representation, hard decision decoding with minimum Hamming distance selection 
is implemented. Both of the above functions follow closely to the explanation provided in 


[7] and are described here. 


I; IFFT / FFT 

An OFDM transmission system typically consists of three stages each for both the 
transmitter and the receiver. This is illustrated in Figure 62. In the transmitter, the serial- 
to-parallel (s/p) converter shall prepare a stack of 64 frequency samples (including pilot 
tones and guard bands) for the IFFT. Sixty-four time samples are generated and cyclic 
prefix shall be inserted to provide redundancy and to mitigate inter-symbol interference 
(ISD. Conversely, at the receiver, the cyclic prefix shall be removed prior to the FFT. 


Sixty-four time samples are sent through the FFT to obtain 64 frequency samples. The 
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pilot tones and guard bands are removed before passing through the parallel-to-serial 


(p/s) converter. 
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-———_} -———_> 
[| > 
























































Figure 62. © OFDM transmission system: transmitter and receiver. 


For a discussion on the DFT, see Chapter 5 of [7]. Two possible types of 
algorithms for DFTs are decimation-in-time (DIT) and decimation-in-frequency (DIF). 
DIT transforms are based on splitting the DFT into two summations: (1) a decimated time 
sequence where even-indexed samples are removed and (2) a decimated time sequence 
where odd-indexed samples are removed. Similarly, DIF transforms split the DFT 
summation into two summations: (1) a decimated frequency sequence where even- 
indexed samples are removed and (2) a decimated frequency sequence where odd- 
indexed samples are removed. For the IEEE 802.11a implementation in this research, the 


DIT approach is chosen. 


If the inputs to either the IFFT or FFT are in natural order, the outputs shall turn 
out to be in bit-reversed order. This is known as natural-input-permutated-output (NIPO). 
Conversely, if the inputs to the transform are in bit-reversed order, the outputs shall turn 
out to be in natural order. This is known as permutated-input-natural-output (PINO). The 


PINO implementation is chosen for this thesis to provide a natural output sequence. 


The above explains the term DIT PINO IFFT/FFT that has been used to describe 
the DFT components in the model. The function flows for both the DATA_IFFT of the 
transmitter and the DATA_FFT of the receiver are shown in Figure 63 for comparisons. It 
is observed that most of the processes within the components remain the same except that 
DIT PINO IFFT is called in DATA_IFFT while DIT PINO FFT is called in DATA_FFT. 
The components can be described by three main processes: (1) convert inputs to complex 
constellations of I and Q samples, (2) reverse the bits for PINO operations and (3) carry 


out either DIT PINO IFFT or DIT PINO FFT. 
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Figure 63. | DATA_IFFT and DATA_FFT functional flows. 
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a. Real to Complex Conversion 

As the inputs to the component are real values, there is a requirement to 
convert them to complex values prior to the DFT. By default, complex number arithmetic 
is not supported in the included libraries. The header file: complex.h has to be included 
before any complex algorithm can be built. The I-channel and Q-channel values shall be 


mapped to the real and imaginary parts of the complex number, respectively. 


Permutated inputs Natural outputs 
x{0] X[0] 
ee x Zs mt 
x[2] X[2] 
x{6] Z X[3] 
x[1] X[4] 
DIT — odd x5] a, X(5] 


samples 























x[3] x(6] 


x[7] X[7] 





Figure 64. A sample signal flow graph of a DIT PINO FFT. 
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b. Bit Reversal 

As explained earlier, PINO is preferred and input bits have to be bit- 
reversed prior to IFFT/FFT operations. A sample of the bit-reversed inputs is shown in 
Figure 64. Notice that the outputs sequence is in natural order due to such arrangement. 

c. DIT PINO DFT 

From Figure 64, it is observed that the DFT is implemented by individual 
‘butterfly’ patterns. This is the backbone of the IFFT/FFT algorithm. Both the DFT and 


inverse DFT are defined in Equation 8 and 9 respectively: 


X [m] = x[n] we" (8) 
x[n]= —> x [m] wie" (9) 


While not going into details of the mathematical operations (see [7] for 
derivations), it is important to realize that both the IFFT and FFT algorithms are almost 


similar except for the exponent of the W,, function and the normalization factor. The 
normalization factor for IFFT is equal to the number of samples (64), while that for the 
FFT is unity. If we let W,,,= Wy” and W,,,= W,’", it can be shown that 


Re(Wp,--)=Re(W,p--) and Im(W,,,)=—Im(W,,,). In other words, if 6 is the 


argument, then the two functions differ as follows: 
Worr= cos(@)+ jsin(@) (10) 


Woprr= cos(@)— jsin(@) (11) 
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2. Viterbi Decoder 
The decoder carries out two main functions: (1) inserting the dummy “zero”’s and 


(2) convolutional decoding using the Viterbi algorithm. The DATA subframe has been 


1 2 
coded with a convolutional encoder of coding rate R= 5 or 7 depending on the 


data rate. The convolutional encoder was described under the transmitter development 
earlier. To compensate for encoder puncturing, dummy “zero” bits need to be inserted 
into the convolutional decoder in place of the omitted bits. Decoding by the Viterbi 
algorithm is preferred, especially for convolutional coding. This sequential functional 
flow is shown in Figure 65. 

a. Initialise_viterbi() 

The Viterbi algorithm with hard decision decoding is based on finding the 
shortest Hamming distance by comparing the received data bits with a set of expected 
code sequences. A lookup matrix is constructed to assist in the process. For DATA 
decoding, the lookup matrix is of size 64 (rows) by 22 (columns). Since the constraint 
length is 7, there are six memory elements in the encoder. This will entail a total of 2° = 
64 different states in the shift register memories, which translates to 64 rows in the 
lookup matrix. The compositions of the 22 columns are provided in Table 18. The lookup 
matrix needs to be initialized prior to the decoding process. This is carried out by the 


initialise_viterbi() function call as shown in Figure 66. 


Rx3.6: Data_conv_dec 


Rx3.6-11: ere 5 
‘ Recover Viterbi decoding 
cass [eee 


Rx3.7: 
Data_deinterleaver 
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Coding rate? r 


i iterate 
i Nsym process_viterbi() 
i times 
Insert dummy 
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Rx3.4: 
Data_descrambler 


Figure 65. | Anexample of Viterbi decoder: DATA_conv_dec functional flow. 
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Column Description Functions 
1...6 Current_state current 6 left most bits in the shift register 
7 ...12 |Next _stated new 6 bits assume input '0' 
13 ...18 |Next_state1 new 6 bits assume input '1' 
19, 20 Conv_output0 convolutional encoder output assume input '0' 
21, 22 Conv_output1 convolutional encoder output assume input '1' 
Table 18. Viterbi decoding lookup matrix. 
initialise_viterbi() -—— einen ae po] egnay  ied| eA ea oe” eo - nye } 
Lace eee ene ae 
i —~ Next 5 i 
ae i Bit O—-< State? Bit 1—-» : 
y iterate ‘N Y : ; ¥ : Bit 1" 
| Nstate=64 Convert Y Y ‘ 
~~ | pe em ~1 Sond store Sits Bio | 
ia lei v v 
p-Store 6 bits--~' | insert bit 0’ at LSB Insert bit ‘1’ at LSB ; | 
| : Y ' ) v Y | ' 
z) + He 7 a | + i a A 
aes >(x) = 
ve Bees Ses ee Sees tese Sees >(X} = 
Tt 
eerie acme encoder Fa Monslacis relied ans neteatnseat 
polynomial 
Figure 66. _initialise_viterbi() functional flow. 
b. Process _viterbi() 


After the lookup matrix has been initialized, the overall data is divided 


into Ny, fixed size bits streams for Viterbi decoding by the process_viterbi() function 


call. The process_viterbi() functional flow is shown in Figure 67. It consists of four main 
procedures: (1) select the corresponding insertion pattern for specific puncturing code, (2) 
initialize the relevant variables, (3) decode using the Viterbi algorithm and (4) make a 
decision by selecting the best code sequence. The code sequence is selected based on the 
path with the shortest Hamming distance. The actual Viterbi decoding is relatively 
complex and involved. It is carried out by the BUTTERFLY_viterbi() subroutine. Looking 
at Figure 67, we can deduce that BUTTERFLY_viterbi() will be called a total of 
(Nora * Nir) times, which could result in potentially lengthy code. Hence, a type- 


state 


defined subroutine BUTTERFLY_viterbi() is defined in the header file: Data_conv_dec.h 


to reduce the length of the code. 
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Figure 67. —_ process_viterbi() functional flow. 











CG BUTTERFLY _viterbi() 

The BUTTERFLY_viterbi() functional flow is described in Figure 68. As 
shown, the expected next bit (either ‘0’ or ‘1’) determines the location on the lookup 
matrix that will be referenced. Dummy bits have been added to compensate for the 
puncturing done at the encoder for different code rate, R. These dummy bits shall NOT 
influence the Hamming distance for each iteration and, hence, will be ignored. A decision 


shall be made to choose the path with the shortest Hamming distance. 
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Figure 68. BUTTERFLY_viterbi() functional flow. 
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* NN. 


iter 


After (N ) iterations, the best path will be chosen based on the 


state 
shortest Hamming distance. This is the output decoded stream that will be passed to 


Data_descrambler component as shown in Figure 65. 


B. OTHER CHALLENGES 

The challenges posted here are to raise awareness of potential considerations 
when coding using OSSIE. The newer version of OSSIE might have tackled the 
challenges but the following are with respect to the current version OSSIE 0.5.0. 

1. Data Synchronisation (Ports Management) 

Great care should be taken when passing parameters between components through 
the input and output ports. Handling of a thread between objects must be monitored 
closely so that there will not be a conflict in parameters and variables being called, which 
can lead to potential logic errors. This is especially critical in the IEEE 802.11a model as 
a component can be referenced a few times. For example, in the transmitter, PPDU_map 
is called three times to process preamble, SIGNAL and DATA subframes. There are 
common variables being used for different functional call, and the sequence of 
referencing different processes in the component is critical. The strategy here is to make 
use of control functions like lock() and unlock() in the defined object. Using PPDU_map 
as an example, the processes flow to maintain data integrity and prevent logic errors in 
the process_data() function call is shown in Figure 69. 

Zz; MIMO Components 

A typical component usually has a single input and single output (SISO) port 
configuration. However, as described above, IEEE 802.11a PHY model does consist of 
components with multiple inputs and multiple outputs (MIMO). One good example is 
PPDU_map in Figure 69. However, the OSSIE environment requires that each input 
(output) port must only be connected to another output (input) port. One must be careful 
to ensure same type of variables are passed between two ports of the same connection 
and be mindful of the potential logic errors described in Section B1. The table of SISO 
and MIMO components with their relevant port types is shown in APPENDIX A to 


demonstrate the potential confusion of different port types. 
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Figure 69. § PPDU_map MIMO and control functional flow. 





3, Control Variables 

Control variables are passed between components for the normal functioning of 
the model. These parameters can either be global constant parameters or dynamic 
parameters that can be modified. For global constants (e.g. number of samples per FFT), 
the strategy is to define them in a header file (global_para.h) that can be assessed by all 
components. These constants are reproduced in APPENDIX B as a reference. As for 
dynamic parameters like RATE and LENGTH fields, these will be passed between 


components by prefixing them to the information transmitted as shown in Figure 70. 
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Figure 70. Transmission of dynamic control variables. 
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In this chapter, the major challenges that were encountered while developing the 
TEEE 802.11a PHY layer model were described. With the transceiver model developed, 
the next phase under the Incremental Development Model is to verify the functionalities 
of the various components. The next chapter shall focus on verifying these functionalities 


using test cases provided in the IEEE 802.1 1a standard. 
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VI. VERIFY 


A. TRANSMITTER 

In this section, functionalities of the transmitter components shall be verified 
based on test cases provided in Annex G of the IEEE 802.11a standard [3]. Similar to 
previous chapters, the section is broken down into preamble, SIGNAL and DATA 
subframes. The example in Annex G consists of ASCII information to be transmitted at a 
data rate of 36 Mbits/s and a total PSDU length of 100 octets (i.e. LENGTH = 100). The 
test results are divided into two categories: summarized and detailed traces. The 
summarized trace is attached in APPENDIX C, which verifies that all components 
carried out their functions accordingly. The entire transmitter test passes through 31 I/O 
sequential flows, and this is summarized in APPENDIX D. The detailed traces in this 
section are described according to (1) the functions of the component, (2) files where the 
test results are traced and stored, and (3) evaluation of the test results. All the files 
mentioned in this chapter have been included in the reference CD. 

LI. Preamble 

Table 19 summarizes the components and their functions to form the preamble 


subframe. The test cases shall demonstrate these specific functions. 





Index Component Functions 

Tx preamble_map - initiate the Tx routine 

- form short training (ST) and long training (LT) sequence 
- send preamble (ST + LT) to PPDU 








Tx1.1 short training (ST) 

















Tx1.1.9 |ST_carrier_map  |- ST carrier mapping 
Tx1.1.10 |ST_IFFT - ST IFFT 

Tx1.2 long training (LT) 

Tx1.2.9 |LT_carrier_map — |- LT carrier mapping 
Tx1.2.10 [LT_IFFT - LT IFFT 

















Tx1.2.11 |LT_cyclicPrefix - LT cyclic prefix append 
Table 19. TEEE 802.11a Transmitter preamble subframe components functionalities. 





a. Tx1: Preamble Mapping (Assembly Controller) 
This component carries out the following functions: (1) initiate the 
transmitter routine, (2) form ST and LT sequences, and (3) append the two sequences and 


form the preamble subframe. The detailed traces are captured in preamble_map.txt and a 
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summary of the traces are provided in Table 20. The traces show that 52 binary bits are 
sent out for processing to form 160 complex samples of ST sequence and follow by 
another set of 52 binary bits that are sent out to form 160 complex samples (I and Q 
channels) of LT sequence. The final sequence of 320 complex samples forms the 


preamble subframe. 











No [Trace Explanations 
1 [Processing short training sequence, size: |52 pre-defined I/Q real samples are sent out for 
52 processing to form the ST sequence. 
2 (Complex float pushpacket received, length |160 I/Q float samples of ST sequence received 
160 and stored for future transmission. 





3 [Processing long training sequence, size: 52/52 pre-defined I/Q real samples are sent out for 
processing to form the LT sequence 





4 |Complex float pushpacket received, length /160 I/Q float samples of LT sequence received 
160 and stored for future transmission 








5 |Processing preamble sequence, size: 320 |ST and LT sequences are cascaded and sent to 
Preamble_append Tx data, Length 320 PPDU_map for future transmission 











Table 20. preamble_map detail traces and explanations. 


b. Tx1.1.9: Carriers Mapping (ST) 

This component carries out the function of carriers mapping on the ST 
sequence. The detailed traces are captured in st_carriers_map.txt and a summary of the 
traces are provided in Table 21. The traces show that 52 binary bits are received and 


catriers-mapped to a size of 64 complex samples for IFFT. 





No Trace Explanations 





1 |Complex short pushpacket received, length [52 pre-defined I/Q real samples received 
52 








2 (Processing ST carrier mapping Mapped into 64 samples for IFFT 
ST_carriers_map Tx data, Length 64 











Table 21. ST_carriers_map detail traces and explanations. 


c. Tx1.1.10: IFFT (ST) 

This component carries out the function of IFFT on the ST sequence. The 
detailed traces are captured in st_ifft.txt and a summary of the traces are provided in 
Table 22. The traces show that 64 complex samples are received and gone through IFFT 


and duplication, to form 160 complex samples. 





No [Trace Explanations 





1 |Complex float pushpacket received, length (64 pre-defined I/Q float samples received 
64 








2 |Processing ST IFFT Mapped into 64 time samples after IFFT 
ST_IFFT Tx data, Length 160 Duplicate to form 160 ST sequence 











Table 22. ST_IFFT detail traces and explanations. 
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d. Tx1.2.9: Carriers Mapping (LT) 

This component carries out the function of carriers mapping on the LT 
sequence. The detailed traces are captured in /t_carriers_map.txt and a summary of the 
traces are provided in Table 23. The traces show that 52 binary bits are received and 


catriers-mapped to a size of 64 complex samples for IFFT. 





No |Trace Explanations 
1 |Complex short pushpacket received, length 52 [52 pre-defined I/Q real samples received 


2 (Processing LT carrier mapping Mapped into 64 samples for IFFT 
LT_carriers_map Tx data, Length 64 


Table 23. LT_carriers_map detail traces and explanations. 




















e. Tx1.2.10: IFFT (LT) 
This component carries out the function of IFFT on the LT sequence. The 
detailed traces are captured in /t_ifft.txt and a summary of the traces are provided in Table 


24. The traces show that 64 complex samples are received and gone through IFFT and 


duplication, to form 128 complex samples. 





No [Trace Explanations 
1 |Complex float pushpacket received, length 64 |64 pre-defined I/Q float samples received 
2 |Processing LT IFFT Mapped into 64 time samples after IFFT 
LT_IFFT Tx data, Length 128 Duplicate to form 128 samples 
Table 24. LT_IFFT detail traces and explanations. 




















f Tx1.2.11: Cyclic Prefix (LT) 

This component carries out the function of appending the cyclic prefix to 
the received complex samples. The detailed traces are captured in /t_cyclicprefix.txt and a 
summary of the traces are provided in Table 25. The traces show that 128 complex 


samples are received and cyclic prefix is appended to form the 160 complex samples of 


LT sequence. 





No [Trace Explanations 
1 |Complex float pushpacket received, length 128 |128 I/Q time samples received 











2 Processing cyclic prefix Add cyclic prefix to form 160 LT sequence 
LT cyclic prefix modulated data, Length 160 


Table 25. LT_cyclicPrefix detail traces and explanations. 











a 





2. SIGNAL 
Table 26 summarizes the components and their functions to form the SIGNAL 


subframe. The test cases shall demonstrate these specific functions. 














Index Component Functions 

Tx2 header_map - form SIGNAL (SIG) samples 
(SIGNAL_map) - send SIG to PPDU 

Tx2.6 SIG_conv_enc - SIG convolutional encoding 

Tx2.7 SIG_interleaver - SIG interleaving 





Tx2.8 SIG_BPSK_mod_|- SIG BPSK modulation 

Tx2.9 SIG_carriers_map |- SIG carriers mapping 

Tx2.10 |SIG_IFFT - SIG IFFT 

Tx2.11  |SIG_cyclicprefix | - SIG cyclic prefix 

Table 26. [EEE 802.11a Transmitter SIGNAL subframe components functionalities. 


























a. Tx2: SIGNAL Mapping 

This component forms the SIGNAL subframe and send the subframe to 
PPDU_map. The detailed traces are captured in signal_map.txt and a summary of the 
traces are provided in Table 27. The traces show that eight binary control bits are 
received to initiate the formation of the SIGNAL subframe. After the processing, the 


SIGNAL subframe, together with 16 control bits, are sent to PPDU_map. 





























No |Trace Explanations 
1 |Real short pushpacket received, length 8 [Received control bits from PPDU_map to start 
SIGNAL processing 

2 |Processing Header sequence, size: 24 Retrieved RATE and LENGTH information. Form 
Processing SIGNAL bits, size: 24 SIGNAL raw bits and send for processing 

3 |Complex float pushpacket received, length 80 I/Q float samples of SIGNAL subframe 
80 received and stored for future transmission 

4 \Processing SIGNAL sequence, size: 80 16 control bits of RATE and LENGTH appended 
Header_append Tx data, Length 96 to 80 I/Q time samples of SIGNAL subframe 





Table 27. | SIGNAL_map detail traces and explanations. 


b. Tx2.6: Convolutional Encoder (SIG) 

This component carries out the function of convolutional encoding for the 
SIGNAL field. The detailed traces are captured in sig_conv_enc.txt and a summary of the 
traces are provided in Table 28. The traces show that 24 binary bits are received and 


encoded to form 48 binary bits. 





No [Trace Explanations 





1 [Real short pushpacket received, length 24 24 SIGNAL raw bits received 








2 |Processing SIG convolution encoding, size: 24 [Encoder R=1/2, hence output 48 encoded bits 
SIG encoded Tx data, Length 48 











Table 28. | S/G_conv_enc detail traces and explanations. 
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Cc. Tx2.7: Interleaver (SIG) 

This component carries out the function of interleaving the encoded 
SIGNAL field. The detailed traces are captured in sig_interleaver.txt and a summary of 
the traces are provided in Table 29. The traces show that 48 binary bits are received and 


interleaved to form 48 binary bits. 














No [Trace Explanations 

1 {Real short pushpacket received, length 48 48 SIGNAL encoded bits received 

2 (Processing SIG interleaver, size: 48 48 bits went through two permutations of 
interleaving 











Table 29. $/G_interleaver detail traces and explanations. 


d. Tx2.8: BPSK Modulation (SIG) 

This component carries out the function of BPSK modulation on the 
interleaved bits. The detailed traces are captured in sig_bpsk_mod.txt and a summary of 
the traces are provided in Table 30. The traces show that 48 binary bits are received and 


modulated to a size of 48 complex BPSK samples. 














No |Trace Explanations 

1 {Real short pushpacket received, length 48 48 SIGNAL interleaved bits received 
Processing BPSK modulation Modulated into 48 BPSK I/Q float samples 
SIG modulated data, Length 48 











Table 30. S/G_BPSK_mod detail traces and explanations. 


e. Tx2.9: Carriers Mapping (SIG) 

This component carries out the function of carriers mapping on the 
SIGNAL field. The detailed traces are captured in sig_carriers_map.txt and a summary 
of the traces are provided in Table 31. The traces show that 48 complex samples are 


received and carriers-mapped to a size of 64 complex samples for IFFT. 





No [Trace Explanations 





1 |Complex float pushpacket received, length 48 48 I/Q float samples received 








2 |Processing carrier mapping Mapped into 64 samples for IFFT 
SIG carriers mapped data, Length 64 











Table 31. $/G_carriers_map detail traces and explanations. 


f Tx2.10: IFFT (SIG) 
This component carries out the function of IFFT on the SIGNAL field. 


The detailed traces are captured in sig_ifft.txt and a summary of the traces are provided in 
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Table 32. The traces show that 64 complex samples are received and gone through IFFT 


to form 64 complex samples. 





No [Trace Explanations 





1 |Complex float pushpacket received, length 64 64 I/Q float samples received 





2 (Processing SIG IFFT Mapped into 64 time samples after IFFT 
SIG_IFFT Tx data, Length 64 

















Table 32. S/IG_IFFT detail traces and explanations. 


g. Tx2.11: Cyclic Prefix (SIG) 

This component carries out the function of appending the cyclic prefix to 
the received complex samples. The detailed traces are captured in sig_cyclicprefix.txt and 
a summary of the traces are provided in Table 33. The traces show that 64 complex 


samples are received and cyclic prefix is appended to form the 80 complex samples of 


SIGNAL subframe. 




















No |Trace Explanations 

1 |Complex float pushpacket received, length (64 I/Q time samples received 
64 

2 |Processing SIG cyclic prefix Add cyclic prefix to form 80 SIGNAL subframe 
SIG_cyclicPrefix Tx data, Length 80 








Table 33. $/G_cyclicPrefix detail traces and explanations. 


3. Data 
Table 34 summarizes the components and their functions to form the DATA 


subframe. The test cases shall demonstrate these specific functions. 






































Index Component Functions 

Tx3 data_map - form time data samples from PSDU 
- send DATA samples to PPDU 

Tx3.4 data_scrambler - scramble the raw data 

Tx3.5 data_tail_replacement |- replace tail with zeroes 

Tx3.6 idata_conv_enc - data convolutional encoding 
- data puncturing 

Tx3.7 data_interleaver - data interleaving 

Tx3.8 data_mod_map - data modulation mapping 

Tx3.9 data_carriers_map - data carriers mapping 

Tx3.10 data_IFFT - data IFFT 

Tx3.11 data_cyclicprefix - data cyclic prefix 

Tx0 idata_PSDU - input PSDU data 














Table 34. IEEE 802.11a Transmitter DATA subframe components functionalities. 
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a. Tx3: DATA Mapping 

This component forms the DATA subframe and send the subframe to 
PPDU_map. The detailed traces are captured in data_map.txt and a summary of the 
traces are provided in Table 35. The traces show that 24 binary control bits are received 
to initiate the formation of the DATA subframe. After retrieving the PSDU information 
bits, the binary bits are sent for processing to form the DATA subframe. The final step 


involves sending the 480 complex samples of DATA subframe to PPDU_map. 


























No |Trace Explanations 
1 {Real short pushpacket received, length 24 (Received control bits from PPDU_map to start 
DATA processing (include RATE and LENGTH) 

2 [Activate PSDU processing Activate transfer of PSDU to DATA_map 
Data Tx Bits, Length 24 

3 |Real short pushpacket received, length 800 800 PSDU raw bits (100 octets) received 

4 |Send raw data for scrambling 864 DATA bits send for processing (PAD bits 
Data Tx Bits, Length 869 added), 5 control bits (CBs) appended 

5 |Complex float pushpacket received, length |480 I/Q DATA time samples received 
480 

6 Send processed data to form PPDU Send DATA time samples to PPDU_map 
Data_append Tx data, Length 480 














Table 35. © DATA_map detail traces and explanations. 


b. Tx3.4: Scrambler (DATA) 

This component carries out the function of scrambling the DATA field. 
The detailed traces are captured in data_scrambler.txt and a summary of the traces are 
provided in Table 36. The traces show that 864 binary bits are received and formed 864 


scrambled bits. Note that there are five control bits being passed between components. 





No |Trace 


Explanations 





1 |Real short pushpacket received, length 869 864 (and 5 CBs) raw bits received 








Processing data in the scrambler 


864 scrambled bits sent out together with 5 
Scrambled data Bits, Length 869 


CBs 











Table 36. © DATA_scrambler detail traces and explanations. 


c. Tx3.5: Tail Replacement (DATA) 

This component carries out the function of replacing the scrambled tail 
bits in the DATA field with non-scrambled “zero” bits. The detailed traces are captured 
in data_tail_replace.txt and a summary of the traces are provided in Table 37. The traces 
show that 864 scrambled bits are received and formed 864 bits after the tail bits are 


replaced. Note that there are five control bits being passed between components. 
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No [Trace 


Explanations 





Real short pushpacket received, length 869 864 (and 5 CBs) scrambled bits received 








Ph} 


Processing tail replacement 
Tail replaced data Bits, Length 869 


864 sent out together with 5 CBs after tail 
replacement 











Table 37. © DATA_tail_replacement detail traces and explanations. 


d. 


This component carries out the function of convolutional encoding for the 


Tx3.6: Convolutional Encoder (DATA) 


DATA field. The detailed traces are captured in data_conv_enc.txt and a summary of the 


traces are provided in Table 38. The traces show that 864 binary bits are received and 
encoded with a coding rate of * (with puncturing) to form 1152 binary bits. Note that 


there are five control bits being passed between components. 














No |Trace Explanations 
1 {Real short pushpacket received, length 869 864 bits received 
2 |Processing Data convolution encoding, size: 864 |86 Mbits/s : coding rate of 3/4, hence 1152 


Puncturing the encoded Data, size: 1152 
Data encoded Tx data, Length 1157 


output bits from 864 input bits. 5 CBs added 
to the transmitted data 











Table 38. © DATA_conv_enc detail traces and explanations. 


e. Tx3.7: Interleaver (DATA) 

This component carries out the function of interleaving the encoded 
DATA field. The detailed traces are captured in data_interleaver.txt and a summary of 
the traces are provided in Table 39. The traces show that 1152 binary bits are received 
and interleaved to form 1152 binary bits. Note that there are five control bits being passed 


between components. 





No [Trace 


Explanations 











1 


Real short pushpacket received, length 1157 


1152 DATA encoded bits received 








Processing Data interleaver, size: 1152 
Data interleaved Tx bits, Length 1157 





1152 bits went through two permutations of 
interleaving 








Table 39. 


f 


DATA_interleaver detail traces and explanations. 


Tx3.8: Modulation Mapping (DATA) 


This component carries out the function of 16-QAM modulation on the 





interleaved bits. The detailed traces are captured in data_mod_map.txt and a summary of 


the traces are provided in Table 40. The traces show that 1152 binary bits are received 
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and modulated to a size of 288 complex 16-QAM samples. Note that there are five 


control bits being passed between components. 














No [Trace Explanations 
1 {Real short pushpacket received, length 1157 1152 DATA interleaved bits received 
Processing 16QAM modulation 36 Mbits/s : 16-QAM modulation, hence 
Data modulated samples, Length 293 modulated into 288 16-QAM I/Q float samples 
with 5 CBs 











Table 40. ©. DATA_mod_map detail traces and explanations. 


g. Tx3.9: Carriers Mapping (DATA) 

This component carries out the function of carriers mapping on the DATA 
field. The detailed traces are captured in data_carriers_map.txt and a summary of the 
traces are provided in Table 41. The traces show that 288 complex samples are received 
and carriers-mapped to a size of 384 complex samples for IFFT. Note that there is only 


one control bit being passed between components. 





No [Trace Explanations 





1 |Complex float pushpacket received, length 288 I/Q float samples received 
293 








2 |Processing carrier mapping Mapped into 6 x 64 samples for IFFT with 1 CB. 
Data carriers mapped data, Length 385 














Table 41. |. DATA_carriers_map detail traces and explanations. 


h. Tx3.10: IFFT (DATA) 

This component carries out the function of IFFT on the DATA field. The 
detailed traces are captured in data_ifft.txt and a summary of the traces are provided in 
Table 42. The traces show that 384 complex samples are received and gone through IFFT 
to form 384 complex samples. Note that there is only one control bit being passed 


between components. 





No [Trace Explanations 





1 |Complex float pushpacket received, length 6 x 64 I/Q float samples received 
385 








2 |Processing DATA IFFT Mapped into 64 time samples after IFFT (6 
DATA_IFFT Tx data, Length 385 iterations), with 1 CB 














Table 42. © DATA_IFFT detail traces and explanations. 
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i. Tx3.11: Cyclic Prefix (DATA) 

This component carries out the function of appending the cyclic prefix to 
the received complex samples. The detailed traces are captured in data_cyclicprefix.txt 
and a summary of the traces are provided in Table 43. The traces show that 384 complex 


samples are received and cyclic prefix is appended to form the 480 complex samples of 
DATA subframe. 





No [Trace Explanations 





1 |Complex float pushpacket received, length 


385 


6 x 64 I/Q time samples received 








2 


Processing Data cyclic prefix 
Data_cyclicPrefix Tx data, Length 480 





Add cyclic prefix (6 x 16 samples) to form 480 
DATA subframe 











Table 43. DATA_cyclicPrefix detail traces and explanations. 


4. PPDU (Final Concatenation) 

The final piece to the transmitter is the function of concatenating the preamble, 
SIGNAL and DATA subframes together and form the PPDU frame. This main control is 
carried out by PPDU_map component. 

Tx12: PPDU Mapping 


This component forms the PPDU frame from the three subframes. The 


a. 


detailed traces are captured in PPDU_map.txt and a summary of the traces are provided 
in Table 44. The traces show that binary control bits are sent to initiate the formation of 
SIGNAL and DATA subframes. The traces also show the retrieval of the preamble, 
SIGNAL and DATA subframes. The final PPDU frame consists of 880 complex samples. 





No [Trace Explanations 





1 |Complex float pushpacket received, length 
320 


480 I/Q Preamble time samples received 





2 |Sent Header control bits 


CB Tx data, Length 8 


Activate SIGNAL subframe processing 





3 |Complex float pushpacket received, length 


96 


80 I/Q SIGNAL time samples received, with 16 
CBs (RATE and LENGTH) 





4 |Sent DATA control bits 


CB Tx data, Length 24 


Activate DATA subframe processing 





5 (Complex float pushpacket received, length 
480 


480 I/Q DATA time samples received 








6 Processing PPDU sequence, size: 880 Final PPDU frame of 880 I/Q time samples to be 


sent out for transmission 











Table 44. © PPDU_map detail traces and explanations 


80 





B. RECEIVER 

In this section, functionalities of the receiver components shall be verified. As 
annex G in the standard only described the transmitter outputs, receiver components are 
tested on their abilities to regenerate the transmitter input data (e.g. the receiver decoder 
outputs should be similar to the transmitter encoder input). Similar to the previous 
section, this section is broken down into preamble, SIGNAL and DATA subframes, and 
the test results are divided into two categories: summarized and detailed traces. The 
summarized trace is attached in APPENDIX C. The entire receiver test passes through 20 
1/O sequential flows, and this is summarized in APPENDIX D. The detailed traces in this 
section are described according to (1) the functions of the component, (2) files where the 
test results are traced and stored, and (3) evaluation of the test results. All the files 
mentioned in this chapter have been included in the reference CD. 

1, Preamble 

Table 45 summarizes the components and their functions to remove the preamble 


subframe. The test cases shall demonstrate these specific functions. 











Index Component Functions 
Rx0 Rx_data - received digitized data stream 
Rx1/Rx12 PPDU_rx - extract the required digitized PPDU stream 


- removed preamble from PPDU 
- send stream for header removal 














Table 45. [EEE 802.11a Receiver preamble subframe components functionalities. 


a. Rx0: Receiver Data (Assembly Controller) 
This component simulates the retrieval of digitize data stream. The 
detailed traces are captured in rx_data.txt and a summary of the traces are provided in 


Table 46. The traces show that 884 complex samples are received. 

















No [Trace Explanations 
1 |Start PPDU digitized receiver 880 time samples received. 4 additional arbitrary 
stream_sizel = 884, stream_sizeQ = 884 __|‘noise’ bits prefix to the stream 





Table 46. | Rx_data detail traces and explanations. 


b. Rx1: PPDU Receiver 
This component carries out the following functions: (1) extract the 
digitized PPDU stream, (2) remove preamble from PPDU, and (3) send stream for 


SIGNAL subframe removal. The detailed traces are captured in ppdu_rx.txt and a 
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summary of the traces are provided in Table 47. The traces show that 320 complex 
samples belonging to the preamble subframe are extracted from the received samples. 


The remaining 560 complex samples are sent out for processing. 





No [Trace Explanations 





1 {Removed preamble from PPDU samples _ Proceed to remove the 320 time samples of 
preamble_sizel = 320, preamble_sizeQ = |Preamble subframe 
320 








2 |Sent PPDU (preamble removed) samples 560 time samples (SIGNAL + DATA subframes) 
PPDU_preamble_removed data, Length ready to be forwarded 
560 











Table 47. | PPDU_rx detail traces and explanations. 


2. SIGNAL 
Table 48 summarizes the components and their functions to extract RATE and 


LENGTH from SIGNAL subframe. The test cases shall demonstrate these specific 


























functions. 
Index Component Functions 
Rx2 Header_rx - remove SIG from PPDU 
(SIGNAL_rx) - send header for processing 

- extract RATE & LENGTH from SIG 
- send received data for processing 

Rx2.11 SIG_cyclicprefix_rem - SIG cyclic prefix removal 

Rx2.10 SIG_FFT - SIG FFT 

Rx2.9 SIG_carriers_demap - SIG carriers demapping 

Rx2.8 SIG_BPSK_demod - SIG BPSK demodulation 

Rx2.7 SIG_deinterleaver - SIG deinterleaving 

Rx2.6 SIG_conv_dec - SIG convolutional decoding 

















Table 48. IEEE 802.11a Receiver SIGNAL subframe components functionalities. 


a. Rx2: SIGNAL Receiver 

This component carries out the following functions: (1) remove SIGNAL 
from PPDU, (2) send SIGNAL subframe to retrieve RATE and LENGTH, and (3) send 
DATA subframe for PSDU retrieval. The detailed traces are captured in header_rx.txt 
and a summary of the traces are provided in Table 49. The traces show that 560 complex 
samples are received and 80 complex samples belonging to SIGNAL subframe are sent 
for processing to retrieve the RATE and LENGTH information bits. The remaining 480 
complex samples belonging to DATA subframe are sent out together with five control 


bits. 
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No |Trace 


Explanations 





1 |Complex float pushpacket received, length 
560 


560 I/Q samples (SIGNAL + DATA subframes) 
received 





2 |Sent SIG time samples for processing ... 
Header removed data output, Length 80 


80 I/Q samples of SIGNAL subframe sent for 
processing 





3  |Real short pushpacket received, length 24 
Processing Data sequence, rate: 36 
Mbits/s, length: 100 octets 


24 single stream of SIGNAL bits received, 
RATE= 36 Mbits/s; LENGTH=100 extracted 








Send raw data for decoding 
Header removed data output, Length 485 





480 DATA I/Q time samples sent for processing, 
with 5 CBs 








Table 49. 


b. 


SIGNAL_rx detail traces and explanations. 


Rx2.11: Cyclic Prefix Removal (SIG) 


This component carries out the function of removing the cyclic prefix 


from the SIGNAL subframe. The detailed traces are captured in sig_cyclicprefix_rem. txt 


and a summary of the traces are provided in Table 50. The traces show that 80 complex 


samples are received and cyclic prefix is removed to form the 64 complex samples. 





No |Trace 


Explanations 





1 |Complex float pushpacket received, length 
80 


80 I/Q SIGNAL time samples received 








2 (Processing SIG cyclic prefix remove 
SIG_cyclicPrefix_rem Tx data, Length 64 





64 I/Q time samples extracted for FFT 








Table 50. 


c. Rx2.10: FFT (SIG) 


SIG_cyclicPrefix_rem detail traces and explanations. 


This component carries out the function of FFT on the SIGNAL subframe. 


The detailed traces are captured in sig_fft.txt and a summary of the traces are provided in 


Table 51. The traces show that 64 complex samples are received and gone through FFT 


to form 64 complex samples. 





No |Trace 


Explanations 





1 |Complex float pushpacket received, length 
64 


64 1/Q float samples received 








2 |Processing SIG FFT 
SIG_FFT Tx data, Length 64 





Mapped into 64 complex subcarriers after FFT 








Table 51. 


d. 


SIG_FFT detail traces and explanations. 


Rx2.9: Carriers Demapper (SIG) 


This component carries out the function of carriers demapping on the 


SIGNAL subframe. The detailed traces are captured in sig_carriers_demap.txt and a 
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summary of the traces are provided in Table 52. The traces show that 64 complex 


samples are received and carriers-demapped to a size of 48 complex samples. 

















No |Trace Explanations 
1 |Complex float pushpacket received, length (64 I/Q subcarriers received 
64 
2 |Processing carrier demapping Mapped into 48 complex constellations for BPSK 
SIG carriers demapped data, Length 48 demodulation 








Table 52. | $/G_carriers_demap detail traces and explanations. 


e. Rx2.8: BPSK Demodulator (SIG) 

This component carries out the function of BPSK demodulation on the 
complex samples. The detailed traces are captured in sig_bpsk_demod.txt and a summary 
of the traces are provided in Table 53. The traces show that 48 complex samples are 


received and demodulated to a size of 48 binary bits. 














No [Trace Explanations 
1 |Complex float pushpacket received, length 48 48 BPSK I/Q float samples received 
2 |Processing SIG BPSK demodulation Demodulated into 48 serial bits 

SIG demodulated data, Length 48 











Table 53. SIG_BPSK_demod detail traces and explanations. 


f Rx2.7: De-Interleaver (SIG) 

This component carries out the function of deinterleaving the demodulated 
SIGNAL field. The detailed traces are captured in sig_deinterleaver.txt and a summary of 
the traces are provided in Table 54. The traces show that 48 binary bits are received and 


deinterleaved to form 48 binary bits. 




















No [Trace Explanations 
1 {Real short pushpacket received, length 48 48 SIGNAL demodulated bits received 
2 (Processing SIG deinterleaver, size: 48 48 bits went through two permutations of 
SIG deinterleaved Tx data, Length 48 deinterleaving 





Table 54. S/G_deinterleaver detail traces and explanations. 


g. Rx2.6: Convolutional Decoder (SIG) 

This component carries out the function of convolutional decoding on the 
SIGNAL field. The detailed traces are captured in sig_conv_dec.txt and a summary of the 
traces are provided in Table 55. The traces show that 48 binary bits are received and 


decoded to form 24 binary bits. 
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No |Trace 


Explanations 





Real short pushpacket received, length 48 


48 SIGNAL bits received for decoding 








Nh) 


return from initialise viterbi 
return from process viterbi 
SIG decoded Tx data, Length 24 





Processing SIG convolution decoding, size: 48 


Show bits went through initialize_viterbi() and 
process _viterbi(). 24 bits produced at end of 
decoding. 








Table 55. 


3. Data 


SIG_conv_dec detail traces and explanations. 


Table 56 summarizes the components and their functions to retrieve PSDU from 


the DATA subframe. The test cases shall demonstrate these specific functions. 















































Index Component Functions 
Rx3 data_rx - receive and send raw data for processing 
- receive and send PSDU data to MAC layer 
Rx3.11 data_cyclicprefix_rem _| - data cyclic prefix removal 
Rx3.10 data_FFT - data FFT 
Rx3.9 data_carriers_demap - data carriers demapping 
Rx3.8 data_demod_map - data demodulation mapping 
Rx3.7 data_deinterleaver - data deinterleaving 
Rx3.6 data_conv_dec - data dummy insertion 
- data convolutional decoding 
Rx3.5 data_tail_replace - not required, encompass in descrambler 
Rx3.4 data_descrambler - descramble the raw data 
Table 56. IEEE 802.11a Receiver DATA subframe components functionalities. 


a. 


Rx3: DATA Receiver 


This component carries out the functions of sending the DATA subframe 


for processing and retrieving the PSDU information bits. The detailed traces are captured 


in data_rx.txt and a summary of the traces are provided in Table 57. The traces show that 


480 complex samples are sent for processing and 864 binary bits belonging to DATA 


field are received. The 800 PSDU information bits are sent out together with a control bit. 





No |Trace 


Explanations 





1 |Complex float pushpacket received, length 
485 


480 I/Q samples (DATA subframes) received, 
with 5 CBs 














2 |Sent raw data for processing ... 480 I/Q samples of DATA subframe sent for 
Data output, Length 485 processing, with 5 CBs 

3 |Real short pushpacket received, length 864 |864 DATA bits received (including PAD bits) 

4 |Send PSDU data to MAC layer ... 800 PSDU bits sent out, including 1 bit of 





PSDU Data output, Length 801 








LENGTH field 





Table 57. 


DATA_rx detail traces and explanations. 
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b. Rx3.11: Cyclic Prefix Removal (DATA) 

This component carries out the function of removing the cyclic prefix 
from the DATA subframe. The detailed traces are captured in data_cyclicprefix_rem.txt 
and a summary of the traces are provided in Table 58. The traces show that 480 complex 
samples are received and cyclic prefix is removed to form the 384 complex samples. 


Note that there are five control bits being passed between components. 





No [Trace Explanations 





1 |Complex float pushpacket received, length 480 I/Q DATA time samples received, with 5 CBs 
485 








2 (Processing Data cyclic prefix remove 6 x 64 I/Q time samples extracted for FFT, with 5 
Data_cyclicPrefix_rem Tx data, Length 389 |CBs 











Table 58. DATA_cyclicPrefix_rem detail traces and explanations. 


c. Rx3.10: FFT (DATA) 

This component carries out the function of FFT on the DATA subframe. 
The detailed traces are captured in data_fft.txt and a summary of the traces are provided 
in Table 59. The traces show that 384 complex samples are received and gone through 
FFT to form 384 complex samples. Note that there are five control bits being passed 


between components. 





No |Trace Explanations 





1 |Complex float pushpacket received, length (6 x 64 I/Q float samples received, with 5 CBs 
389 








2 |Processing DATA FFT Mapped into 6 x 64 complex subcarriers after 
DATA_FFT Tx data, Length 389 FFT, with 5 CBs 











Table 59. DATA_FFT detail traces and explanations. 


d. Rx3.9: Carriers Demapper (DATA) 

This component carries out the function of carriers demapping on the 
DATA subframe. The detailed traces are captured in data_carriers_demap.txt and a 
summary of the traces are provided in Table 60. The traces show that 384 complex 
samples are received and carriers-demapped to a size of 288 complex samples. Note that 


there are five control bits being passed between components. 





No [Trace Explanations 





1 |Complex float pushpacket received, length [6 x 64 I/Q subcarriers received, with 5 CBs 
389 








2 Processing data carrier demapping Mapped into 6 x 48 complex constellations for 
Data carriers demapped data, Length 293 (demodulation, with 5 CBs 











Table 60. DATA_carriers_demap detail traces and explanations. 
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e. Rx3.8: Demodulation Mapper (DATA) 

This component carries out the function of 16-QAM demodulation on the 
complex samples. The detailed traces are captured in data_demod_map.txt and a 
summary of the traces are provided in Table 61. The traces show that 288 complex 
samples are received and demodulated to a size of 1152 binary bits. Note that there are 


five control bits being passed between components. 





No [Trace Explanations 





1 |Complex float pushpacket received, length 293 


6 x 48 I/Q float samples received, with 5 CBs 








2 |Processing Data demodulation 
Conduct 16QAM demodulation 
Data demodulated data, Length 1157 





16-QAM demodulation carried out 
Demodulated into (288 x 2 x 2) 1152 serial 
bits, with 5 CBs 








Table 61. © DATA_demod_map detail traces and explanations. 


f Rx3.7: De-Interleaver (DATA) 

This component carries out the function of deinterleaving the demodulated 
DATA field. The detailed traces are captured in data_deinterleaver.txt and a summary of 
the traces are provided in Table 62. The traces show that 1152 binary bits are received 
and deinterleaved to form 1152 binary bits. Note that there are five control bits being 


passed between components. 





No [Trace Explanations 





1 {Real short pushpacket received, length 1157 1152 DATA demodulated bits received 








Processing Data deinterleaver 
Data deinterleaved Tx data, Length 1157 


1152 bits went through two permutations of 
deinterleaving, excluding 5 CBs 











Table 62. © DATA_deinterleaver detail traces and explanations. 

g. Rx3.6: Convolutional Decoder (DATA) 

This component carries out the function of convolutional decoding on the 
DATA field. The detailed traces are captured in data_conv_dec.txt and a summary of the 
traces are provided in Table 63. The traces show that 1152 binary bits are received and 
decoded to form 864 binary bits. Note that there are five control bits being passed 


between components. 





No |Trace Explanations 





1152 DATA bits received 








1 [Real short pushpacket received, length 1157 
2 |Processing DATA convolution decoding 
return from initialise viterbi 

return from process viterbi 

DATA decoded Tx data, Length 869 


Show bits went through initialize_viterbi() and 
process _viterbi(). 864 bits obtained at end of 
dummy insertion and decoding, with 5 CBs 











Table 63. © DATA_conv_dec detail traces and explanations. 
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h. Rx3.4: Descrambler (DATA) 


This component carries out the function of descrambling the DATA bits. 


The detailed traces are captured in data_descrambler.txt and a summary of the traces are 


provided in Table 64. The traces show that 869 binary bits are received and formed 864 


descrambled bits. 





No 


Trace 


Explanations 





1 


Real short pushpacket received, length 869 


864 DATA bits received after decoding 








2 


Processing data in the descrambler 
Descrambled data Bits, Length 864 





864 DATA bits descrambled (including PAD 





bits) 





Table 64. © DATA_descrambler detail traces and explanations. 


In this chapter, the functionalities of the transmitter and receiver OSSIE models 


have been verified using test cases provided in the IEEE 802.1la standard. With this 


success in mind, the next chapter shall conclude the thesis research and provide 


recommendations for further research. 
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VII. CONCLUSION 


A. SUMMARY 

Software defined radio has been the emerging trend of radio design both in the 
commercial and military arena. Wireless LAN standards like IEEE 802.11la have been 
among the popular physical means of data transmission. This thesis lays the groundwork 
for implementing an IEEE 802.11a standard using open source software for SDR design. 
Critical functionalities at the Physical layer have been implemented and the convenience 
and flexibilities of using software to implement a popular radio standard as compared to 


expensive and rigid radio implementation using hardware components demonstrated. 
In this thesis, we have successfully met the objectives defined in Chapter I: 


1. The IEEE 802.11a PHY layer transmitter has been built using a total of 23 
OSSIE components with 12 different functionalities and 31 sequential I/O processes. 
Correspondingly, the receiver is implemented using 18 components with 12 different 


functionalities and 20 sequential I/O processes. 


2. All these components have been designed with modularity and flexibility in 
mind so that they contribute to the pool of components for future radio design. Most of 
the functionalities reside in the process_data() functional call within the component C++ 
file for standardization and ease of debugging. “Readme” files are also included in each 
component’s directory to explain its I/O data types, functionalities and assumptions. 
Appropriate parameters can be modified easily for use in other transceivers. All the files 


mentioned in this research have been included in the reference CD. 


3. With the design implemented fully in OWD environment, the SDR conforms to 
Software Communications Architecture (SCA) and the Common Object Request Broker 
Architecture (CORBA). This will ensure flexibility, performance and maximum potential 


for software module reuse. 


4. Using the test cases provided in Annex G of the IEEE 802.1la standard 
document, all the components have been verified to provide the necessary functionalities 


expected of them. 
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OSSIE, being developmental software, has yet to release its full version. Most of 
the efforts from the OSSIE developers are channeled to fix bugs and enhance the 
software, rather then using the software to develop communications standards. This thesis 
leverages on the capabilities of the software, adapts it to a popular communication 
standard and advances OSSIE capabilities by demonstrating that such a marriage can be 


implemented with an integration of OSSIE components into a working waveform. 


The Incremental Development Model was chosen for this thesis, which is 
comprised of three stages: Design, Develop and Verify. The advantage of this model is its 
incremental nature, which allows the developer to learn from earlier versions of the 
system and enhance the subsequent design. It provides a systematic approach of meeting 
the objectives of the thesis by adding verified components into the library and eventually 


forming the final product. 


B. RECOMMENDATIONS 

The software components developed here shall serve as a baseline to link up with 
other software or hardware components to implement a fully functional IEEE 802.11la 
transceiver. For this to happen, the following are potential areas to address in order to 


implement such a functional transceiver: 


a) Map up the hardware resources needed such as the type of General Purpose 
Processor (GPP) or Field Programmable Gate Array (FPGA) to implement 
the functions of the components. The Universal Software Radio Peripheral 
(USRP) board is a hardware option to be considered as part of the RF front 
end and is a low cost and high-speed hardware component suitable to 
implement research-based software radio applications. A good reference is a 
course project setup by Virginia Tech that utilizes USRP and OSSIE to 


implement a SDR receiver [8]. 


b) Synchronization of the receiver for packets detection. As this research is done 
at baseband, it will be interesting to observe its performance in the 5GHz 
carrier frequencies range for the IEEE 802.11a standard. These filtering and 


synchronizing functions at higher frequencies would most likely be 
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implemented using hardware, but the possibilities of extending the software 


capabilities to the RF front end should also be considered. 


c) Presence of channel noise and multi-path fading may lead to amplitude and 
phase errors in the received signals. The model needs to be modified to 
compensate for such perturbations. One proposal is to consider the use of 


diversity SDR receiver with central combiner 


With the potential of implementing a fully functional radio standard, the follow 
up could be to use the developed components to test out the channel performances like 
Bit Error Rates (BER). Since the SDR is supposed to be modular and reconfigurable, its 
ability to be flexible in a dynamically changing environment can be further explored by 


changing parameters like the information bit rates in real time. 


Academically, collaboration and research with Virginia Tech can be enhanced 
with this family of components. The experiences and development carried out in this 


thesis can also be exemplified for SDR education and training. 
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APPENDIX B: GLOBAL PARAMETERS 


[BR KK IKK KK KR KAR I A RR I AR AR A I AR IA IK A I I He 


This file lists all the global constants referenced in the OSSIE 
IEEE 802.1la Transceiver Design. 


FER IRR IR AR I A IR AR I A I AR IA I A I A I AR I II I I I / 


/* Transmitter control parameters */ 


const float Fsym = 20.0; // OFDM symbol frequency spacing (20 MHz) 

const float Fsub = Fsym / 64.0; // OFDM symbol subcarrier freq spacing (20MHz/64) 
const float Tifft = 1.0 / Fsub; // IFFT / FFT period (3.2 micro-second) 

const float Tshort = 10.0*Tifft/4.0; // short training sequence duration (8 micro-second) 
const float Tgi2 = Tifft/2.0; // training symbol GI duration (1.6 micro-second) 


const float Tlong = Tgi2 + 2.0*Tifft; // long training sequence duration (8 micro-second) 
const float Tpreamble = Tshort + Tlong; // PLCP preamble duration (16 micro-second) 


const float Tcep = Tifft/4.0; // cyclic prefix for header (0.8 micro-second) 
const float Theader = Tifft+ Tcp; // PLCP header duration (4 micro-second) 
const float Tsample = 1.0 / Fsym; // sample period (0.05 micro-second) 





const float null=0.0; 











const int octet=8; // size of an octet 

const int Nrb = 4; // no. of RATE bits 

const int Nlb = 12; // no. of LENGTH bits 

const int Ntb = 6; // no. of TAIL bits 

const int Nsb = 24; // no. of SIGNAL bits 

const int Nserb = 16; // no. of SERVICE bits 

const int Nscrb = 7; // no. of syn descramble bits 

const int RES=0; // veserve for future use 

const int Nsd = 48; // no. of data subcarriers 

const int Nsp = 4; // no. of pilot subcarriers 

const int Nst = Nsd + Nsp; // no. of total subcarriers 

const int Ntr = 52; // no. of bits per training symbol 
const int guard_len = 12; // total guard band carriers 

const int ifft_len = Nst + guard_len; // total OFDM IFFT length 

const int num_samples = ifft_len; // no. of sub_carriers 

const int cb_length = 8; // length of control bits 

const int cp_len_DATA = ifft_len/4; // DATA and SIG cyclic prefix length 
const int cp_len_preamble = ifft_len/2; // Preamble cyclic prefix length 

/* Receiver control parameters */ 

const float Fsym = 20.0; // OFDM symbol frequency spacing (20 MHz) 
const float Fsub = Fsym / 64.0; // OFDM symbol subcarrier freq spacing (20MHz/64) 
const float Tifft = 1.0 / Fsub; // IFFT / FFT period (3.2 micro-second) 
const float Tcp = Tifft/4.0; // cyclic prefix (0.8 micro-second) 
const float Theader = Tifft+ Tcp; // PLCP header duration (4 micro-second) 
const float Tsample = 1.0 / Fsym; // sample period (0.05 micro-second) 





const float null = 0.0; 

















const int octet=8; 

const int Nrb = 4; // no. of RATE bits 

const int Nlb = 12; // no. of LENGTH bits 

const int Ntb = 6; // no. of TAIL bits 

const int Nsb = 24; // no. of SIGNAL bits 

const int Nserb = 16; // no. of SERVICE bits 

const int Nscrb = 7; // no. of syn descramble bits (7 bits) 
const int Nsd = 48; // no. of data subcarriers 
const int Nsp = 4; // no. of pilot subcarriers 
const int Nst = Nsd + Nsp; // no. of total subcarriers 
const int guard_len = 12; // total guard band carriers 
const int fft_len = Nst + guard_len; // total OFDM IFFT length 
const int cp_len = fft_len/4; // cyclic prefix length 
const int num_samples = fft_len; // no. of sub_carriers 

const int Nsr=6; // no. of shift registers 
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APPENDIX C: SUMMARIZED TRACE 


A. TRANSMITTER 


KKKKKKKKKKKKKKKKKKKKKKKKK KKK KKK KKK KK 


Welcome to OSSIE simulation: 802.1la PPDU transmission 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Start process data function 

Processing short training sequence, size: 52 

Tx training data, Length 52 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start ST_carriers_map function 

KKK KKK KKK KK KKK KK KKK KKKKKKKEKKKAKKAKKKKK 

Complex short pushpacket received, length 52 
Processing ST carrier mapping 
ST_carriers_map Tx data, Length 64 

KKK KKKK KK KK KKK KKKKKEKKKKKKKKKKAKKAKKKKK 


Start ST_IFFT function 

ST he te eee ee ie ee he eee ee ee ee ee Ne eee Bee ee 

Complex float pushpacket received, length 64 
Processing ST IFFT 

IFFT time output (Magnitude), Length 64 
ST_IFFT Tx data, Length 160 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Start Preamble_append function 

KKK KKKK KK KK KKK KKKKKEKKKEKKKKKKKAKKAKKKKK 

Complex float pushpacket received, length 160 
Processing short training sequence storage, size: 160 
Processing long training sequence, size: 52 

Tx training data, Length 52 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start LT_carriers_map function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Complex short pushpacket received, length 52 
Processing LT carrier mapping 
LT_carriers_map Tx data, Length 64 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start LT_IFFT function 

KKK KK KK KK KK KKK KKKEKKEKKKKKKKKKKAKKAKKKKK 

Complex float pushpacket received, length 64 
Processing LT IFFT 

IFFT time output (Magnitude), Length 64 
LT_IFFT Tx data, Length 128 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Start LT_cyclicPrefix function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Complex float pushpacket received, length 128 
Processing cyclic prefix 

LT cyclic prefix modulated data, Length 160 
LT_cyclicPrefix Tx data, Length 160 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Preamble_append function 

KKK KKK KK KKK KK KKK KKEKKEKKKKKKKKAKKAKKKKK 

Complex float pushpacket received, length 160 
Processing long training sequence storage, size: 160 
Processing preamble sequence, size: 320 
Preamble_append Tx data, Length 320 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start PPDU_append function 

KKK KKK KK KKK KKKKKKKKKKKKKKKKKAKKKKKKK 

Complex float pushpacket received, length 320 
Processing Preamble sequence, size: 320 

Sent Header control bits 

CB Tx data, Length 8 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIGNAL_mapping function 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Real short pushpacket received, length 8 
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Processing Header sequence, size: 24 

Enter the Rate of the data bits: (Mbit/s) 36 

Enter the no. of PSDU Octets to be transmitted: 100 
Processing SIGNAL bits, size: 24 

SIG Bits, Length 24 


KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIGNAL_encoding function 

KKK K KKK KK KK KKK KKK KKEKKKKKKKEKKKAKKAKKKKK 

Real short pushpacket received, length 24 
Processing SIG convolution encoding, size: 24 
SIG encoded Tx data, Length 48 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIGNAL_interleaver function 
DEERE IO TR TER IEE IE RE EEE EE REE EEE PES 





Real short pushpacket received, length 48 
Processing SIG interleaver, size: 48 
SIG interleaved Tx data, Length 48 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIG_modulation function 

KKK KK KK KKKKKKKKKKKKEKKKKKKKKKKAKKKKKKK 

Real short pushpacket received, length 48 
Processing BPSK modulation 

SIG modulated data, Length 48 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIG_carriers_map function 

KKK KK KK KKK KKK KKKKKKEKKKKKKKKKKKKKKKKK 

Complex float pushpacket received, length 48 
Processing carrier mapping 

SIG carriers mapped data, Length 64 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIG_IFFT function 

RE TO RE EE ERE EE REESE EERE EES 
Complex float pushpacket received, length 64 
Processing SIG IFFT 

IFFT time output (Magnitude), Length 64 
SIG_IFFT Tx data, Length 64 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIG_cyclicPrefix function 

KKK KKK KK KK KKK KKKEKKEKKEKKKKKKKKAKKAKKKKK 

Complex float pushpacket received, length 64 
Processing SIG cyclic prefix 
SIG_cyclicPrefix Tx data, Length 80 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIGNAL_append function 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Complex float pushpacket received, length 80 
Processing SIGNAL sequence, size: 80 
Header_append Tx data, Length 96 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start PPDU_append function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Complex float pushpacket received, length 96 
Processing Header sequence, size: 96 

Sent DATA control bits 

CB Tx data, Length 24 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_mapping function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Real short pushpacket received, length 24 

Processing Data sequence, rate: 36 Mbit/s, length: 100 octets 
Activate PSDU processing 

Data Tx Bits, Length 24 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_PSDU function 

KKK KK KKK KKK KKK KK KKK KKKKKKKEKKKAKKAKKKKK 

Real short pushpacket received, length 24 
Start PSDU retrieval 

PSDU Tx Bits, Length 800 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 








Start Data_mapping function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
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Real short pushpacket received, length 800 
Retrieve PSDU data 

Append and form raw data packet 

Send raw data for scrambling 

Data Tx Bits, Length 869 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_scrambler function 
KKK K KKK KK KKK KK KKK KKEKKKKKKKEKKKAKKAKKKKK 





Real short pushpacket received, length 869 
Processing data in the scrambler 
Scrambled data Bits, Length 869 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_tail_replacement function 

Ge i the he A ee Mi Se he Ne ae Ne oe ee ee ei ee i 

Real short pushpacket received, length 869 
Processing tail replacement 

Tail replaced data Bits, Length 869 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_encoding function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Real short pushpacket received, length 869 
Processing Data convolution encoding, size: 864 
Puncturing the encoded Data, size: 1152 

Data encoded Tx data, Length 1157 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_interleaver function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Real short pushpacket received, length 1157 
Processing Data interleaver, size: 1152 
Data interleaved Tx bits, Length 1157 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Start Data_modulation function 

KKK KK KK KK KKK KK KKK KKEKKKKKKKKAKKKKAKKKKK 

Real short pushpacket received, length 1157 
Processing data modulation 

Data modulated samples, Length 293 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 








Start Data_carriers_map function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Complex float pushpacket received, length 293 
Processing carrier mapping 

Data carriers mapped data, Length 385 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_IFFT function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Complex float pushpacket received, length 385 
Processing Data IFFT 

IFFT time output (Magnitude), Length 384 
Data_IFFT Tx data, Length 385 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_cyclicPrefix function 

KKK KKK KKK KKKKKKKKKEKKKKKKKKKKAKKKKKKK 

Complex float pushpacket received, length 385 
Processing Data cyclic prefix 
Data_cyclicPrefix Tx data, Length 480 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_append function 

KEKE KKK KK KKK KK KK KK KKK KKKKKKKKKKAKKKKK 

Complex float pushpacket received, length 480 
Retrieve processed Data samples 

Send processed data to form PPDU 

Data_append Tx data, Length 480 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start PPDU_append function 

KKK K KKK KKK KKK KKK KK KKK KKKKKEKKKKKAKKKKK 

Complex float pushpacket received, length 480 

Processing Data sequence, size: 480 

Processing PPDU sequence, size: 880 

PPDU octect 0: 0.0459988 + 0.04599884; -0.132444 + 0.002339594; -0.0134727 + -0.07852483; 
0.142755 + -0.01265125; 0.0919975 + 6.18545e-094; 0.142755 + -0.01265125; -0.0134727 + - 
0.0785248 5; -0.132444 + 0.0023395874; 
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voOoOouwOoO | 
Woe oe . 


vootwvo! 











eis voov0ceCo VTC OVO 1 


U octect 1: 0.0459988 + 0.0459988)j; 0.0023396 + -0.132444 3; -0.0785248 + -0.01347273; 
-0126512 + 0.1427553; 4.31489e-09 + 0.09199755; -0.0126512 + 0.14275545; -0.0785248 + - 
347273; 0.00233958 + -0.1324443; 
U octect 2: 0.0459988 + 0.0459988 4; -0.132444 + 0.002339595; -0.0134727 + -0.0785248j4; 
42755 + -0.01265123; 0.0919975 + 6.18545e-094j; 0.142755 + -0.01265125; -0.0134727 + - 
7852485; -0.132444 + 0.002339583; 
U octect 3: 0.0459988 + 0.0459988)j; 0.0023396 + -0.132444j3; -0.0785248 + -0.01347273; 
-0126512 + 0.14275535; 4.31489e-09 + 0.09199755; -0.0126512 + 0.1427553; -0.0785248 + - 
347273; 0.00233958 + -0.1324443; 
U octect 4: 0.0459988 + 0.0459988 4; -0.132444 + 0.002339594; -0.0134727 + -0.0785248]4; 
42755 + -0.01265123; 0.0919975 + 6.18545e-09j; 0.142755 + -0.01265125; -0.0134727 + - 
7852485; -0.132444 + 0.002339583; 

U octect 5: 0.0459988 + 0.0459988)j; 0.0023396 + -0.1324443; -0.0785248 + -0.01347273; 
-0126512 + 0.1427553; 4.31489e-09 + 0.09199755; -0.0126512 + 0.1427553; -0.0785248 + - 
1347275; 0.00233958 + -0.1324443; 
U octect 6: 0.0459988 + 0.0459988 4; -0.132444 + 0.002339593; -0.0134727 + —-0.0785248j4; 
42755 + -0.01265123; 0.0919975 + 6.18545e-094; 0.142755 + -0.01265125; -0.0134727 + - 
7852485; -0.132444 + 0.002339583; 

U octect 7: 0.0459988 + 0.04599883j; 0.0023396 + -0.132444 3; -0.0785248 + -0.01347273; 
-0126512 + 0.1427553; 4.31489e-09 + 0.09199755; -0.0126512 + 0.14275543; -0.0785248 + - 
1347275; 0.00233958 + -0.1324443; 
U octect 8: 0.0459988 + 0.0459988 4; -0.132444 + 0.002339594; -0.0134727 + —-0.0785248j; 
42755 + -0.01265123; 0.0919975 + 6.18545e-09j; 0.142755 + -0.01265125; -0.0134727 + - 
7852485; -0.132444 + 0.002339583; 

U octect 9: 0.0459988 + 0.0459988)j; 0.0023396 + -0.1324443; -0.0785248 + -0.01347273; 
-0126512 + 0.142755)5; 4.31489e-09 + 0.09199755; -0.0126512 + 0.14275543; -0.0785248 + - 
013472745; 0.00233958 + -0.1324443; 
DU octect 10: 0.0459988 + 0.04599884; -0.132444 + 0.002339594; -0.0134727 + - 
-078524845; 0.142755 + -0.0126512j5; 0.0919975 + 6.18545e-095; 0.142755 + -0.01265125; - 

0 
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134727 + -0.07852483; -0.132444 + 0.00233958); 
U octect 11: 0.0459988 + 0.0459988j; 0.0023396 + -0.1324444j; -0.0785248 + -0.01347273; 
20126512 + 0.1427553; 4.31489e-09 + 0.09199755; -0.0126512 + 0.14275543; -0.0785248 + - 
013472743; 0.00233958 + -0.1324443; 
DU octect 12: 0.0459988 + 0.04599884j; -0.132444 + 0.002339594; -0.0134727 + - 
-07852484; 0.142755 + -0.012651245; 0.0919975 + 6.18545e-095; 0.142755 + -0.01265125; - 
0 

D 








34727 + -0.07852485; -0.132444 + 0.002339583; 
U octect 13: 0.0459988 + 0.0459988j; 0.0023396 + -0.1324443; -0.0785248 + -0.01347273; 
20126512 + 0.1427553; 4.31489e-09 + 0.09199755; -0.0126512 + 0.1427554; -0.0785248 + - 
13472735; 0.00233958 + -0.1324443; 
U octect 14: 0.0459988 + 0.0459988j; -0.132444 + 0.002339593; -0.0134727 + - 
7852485; 0.142755 + -0.01265125; 0.0919975 + 6.18545e-0943; 0.142755 + -0.01265125; - 
34727 + -0.078524845; -0.132444 + 0.00233958)4; 
U octect 15: 0.0459988 + 0.0459988j; 0.0023396 + —-0.132444j; -0.0785248 + -—0.01347274; 
-0126512 + 0.14275553; 4.31489e-09 + 0.09199755; -0.0126512 + 0.1427554; -0.0785248 + - 
347273; 0.00233958 + -0.1324443; 
U octect 16: 0.0459988 + 0.0459988j; -0.132444 + 0.002339593; -0.0134727 + - 
7852485; 0.142755 + -0.01265125; 0.0919975 + 6.18545e-094j; 0.142755 + -0.01265125; - 
34727 + -0.07852485; -0.132444 + 0.00233958)4; 
U octect 17: 0.0459988 + 0.04599883; 0.0023396 + -0.132444j; -0.0785248 + -0.01347273; 
-0126512 + 0.14275553; 4.31489e-09 + 0.09199755; -0.0126512 + 0.1427554; -0.0785248 + - 
347273; 0.00233958 + -0.1324443; 
U octect 18: 0.0459988 + 0.0459988j; -0.132444 + 0.0023395945; -0.0134727 + - 
78524853; 0.142755 + -0.01265125; 0.0919975 + 6.18545e-094j; 0.142755 + -0.012651235; - 
34727 + -0.07852485; -0.132444 + 0.002339583; 
U octect 19: 0.0459988 + 0.04599883; 0.0023396 + -0.132444j; -0.0785248 + -0.01347273; 
-0126512 + 0.14275553; 4.31489e-09 + 0.09199755; -0.0126512 + 0.1427554; -0.0785248 + - 
347273; 0.00233958 + -0.1324443; 

U octect 20: -0.15625 + 03; 0.0122846 + -0.09759965; 0.0917165 + -0.1058724; - 

918875 + -0.1151294; -0.00280594 + -0.053774335; 0.0750737 + 0.074040443; -0.127324 + 
2050143; -0.121887 + 0.01656623; 

U octect 21: -0.0350413 + 0.150888 3; -0.0564551 + 0.02180393; -0.0603101 + - 

8128615; 0.0695568 + -0.01412245; 0.0822183 + -0.09235654; -0.131263 + -0.065227235; 
572063 + -0.0392986j; 0.0369179 + -0.09834413; 





















































U octect 22: 0.0625 + 0.06253; 0.119239 + 0.004095645; -0.0224832 + -0.1606574; 
586688 + 0.0149393; 0.0244759 + 0.0585318j; -0.136805 + 0.04737984; 0.000988971 + 
150053; 0.0533377 + -0.004076333; 

U octect 23: 0.0975412 + 0.02588833; -0.038316 + 0.10617135; -0.115131 + 0.05518053; 
598238 + 0.08770675; 0.0211118 + -0.02788593; 0.0968318 + -—0.082797945; 0.0397497 + 
111585; -0.00512124 + 0.120325j; 
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U octect 24: 0.15625 + 03; -0.00512125 + -0.1203254; 0.0397497 + -0.1111585; 0.0968319 
.08279793; 0.0211118 + 0.02788594; 0.0598238 + -0.08770684; -0.115131 + -0.05518053; - 
38316 + -0.1061713; 

octect 25: 0.0975412 + -0.02588834; 0.0533377 + 0.004076353; 0.000988968 + - 

50054; -0.136805 + -0.04737984; 0.0244759 + -0.05853184; 0.0586688 + -0.0149394; 
24832 + 0.1606574; 0.119239 + -0.004095563; 

octect 26: 0.0625 + -0.06254; 0.0369179 + 0.09834414; -0.0572063 + 0.03929864; - 
1263 + 0.06522724; 0.0822183 + 0.09235653; 0.0695568 + 0.0141223; -0.0603101 + 

28613; -0.0564551 + -0.02180394; 

U octect 27: -0.0350412 + -0.1508884; -0.121887 + -0.01656623; -0.127324 + - 

2050143; 0.0750737 + -0.07404044; -0.00280595 + 0.05377423; -0.0918875 + 0.1151293; 
917165 + 0.1058725; 0.0122846 + 0.09759953; 

octect 28: -0.15625 + 04; 0.0122846 + -0.09759964; 0.0917165 + -0.1058723; - 

8875 + -0.1151294; -0.00280594 + -0.05377434; 0.0750737 + 0.07404044; -0.127324 + 
050144; -0.121887 + 0.01656623; 
octect 29: -0.0350413 + 0.1508884; -0.0564551 + 0.02180393; -0.0603101 + - 

28614; 0.0695568 + -0.0141224; 0.0822183 + -0.09235654; -0.131263 + -0.06522723; 
72063 + -0.03929864; 0.0369179 + -0.09834413; 

U octect 30: 0.0625 + 0.06254; 0.119239 + 0.00409564; -0.0224832 + -0.1606573; 

586688 + 0.0149394; 0.0244759 + 0.05853184; -0.136805 + 0.04737984; 0.000988971 + 
150053; 0.0533377 + -0.004076334; 

U octect 31: 0.0975412 + 0.02588834; -0.038316 + 0.1061713; -0.115131 + 0.05518053; 
598238 + 0.08770674; 0.0211118 + -0.02788593; 0.0968318 + -0.08279793; 0.0397497 + 
1115835; -0.00512124 + 0.1203254; 

U octect 32: 0.15625 + 03; -0.00512125 + -0.1203254; 0.0397497 + -0.1111583; 0.0968319 
.08279794; 0.0211118 + 0.02788594; 0.0598238 + -0.08770684; -0.115131 + -0.05518053; - 
38316 + -0.1061713; 
U octect 33: 0.0975412 + -0.02588834; 0.0533377 + 0.004076353; 0.000988968 + - 
150053; -0.136805 + -0.04737984; 0.0244759 + -0.05853183; 0.0586688 + -0.0149394; - 
224832 + 0.1606573; 0.119239 + -0.004095563; 

octect 34: 0.0625 + -0.06254; 0.0369179 + 0.09834414; -0.0572063 + 0.03929863; - 
263 + 0.06522724; 0.0822183 + 0.09235653; 0.0695568 + 0.0141224; -0.0603101 + 
28614; -0.0564551 + -0.02180393; 

octect 35: -0.0350412 + -0.1508884; -0.121887 + -0.01656623; -0.127324 + - 
050144; 0.0750737 + -0.07404043; -0.00280595 + 0.05377424; -0.0918875 + 0.1151293; 
7165 + 0.1058724; 0.0122846 + 0.09759954; 
octect 36: -0.15625 + 04; 0.0122846 + -0.09759964; 0.0917165 + -0.1058723; - 

8875 + -0.1151294; -0.00280594 + -0.05377434; 0.0750737 + 0.07404044; -0.127324 + 
050144; -0.121887 + 0.01656623; 
octect 37: -0.0350413 + 0.1508884; -0.0564551 + 0.02180394; -0.0603101 + - 

28614; 0.0695568 + -0.0141224; 0.0822183 + -0.09235653; -0.131263 + -0.06522723; - 
72063 + -0.03929864; 0.0369179 + -0.09834413; 

U octect 38: 0.0625 + 0.06254; 0.119239 + 0.00409563; -0.0224832 + -0.1606573; 
586688 + 0.0149394; 0.0244759 + 0.05853184; -0.136805 + 0.04737984; 0.000988971 + 
150053; 0.0533377 + -0.004076334; 

U octect 39: 0.0975412 + 0.02588834; -0.038316 + 0.1061713; -0.115131 + 0.05518053; 
598238 + 0.08770674; 0.0211118 + -0.02788593; 0.0968318 + -0.08279793; 0.0397497 + 
1115835; -0.00512124 + 0.1203253; 
U octect 40: 0.0625 + 03; 0.0330338 + -0.04385274; -0.00196556 + -0.0376273; 

809046 + 0.08443053; 0.00677414 + -0.1001514; -0.00124631 + -0.11330235; -0.0211465 + - 
04640194; 0.135693 + -0.104693; 
octect 41: 0.0975413 + -0.04419424; 0.0112075 + -0.001832594; -0.0327044 + 

407994; -0.0604833 + 0.1242274; 0.0101382 + 0.09660194; 0.000441049 + -0.007769563; 
83601 + -0.08250373; -0.0692837 + 0.02673353; 
U octect 42: -0.21875 + 04; -0.0692838 + -0.02673353; 0.0183601 + 0.08250373; 

00441058 + 0.007769544; 0.0101382 + -0.09660193; -0.0604833 + -0.1242274; -0.0327044 + 
0.044084; 0.0112075 + 0.001832583; 
U octect 43: 0.0975413 + 0.04419424; 0.135693 + 0.104693; -0.0211466 + 0.004640193; - 
0124632 + 0.1133024; 0.00677412 + 0.1001514; -0.0809046 + -0.08443053; -0.00196555 + 
376274; 0.0330337 + 0.04385273; 
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DU octect 44: 0.0625 + O03; 0.0572128 + 0.052497335; 0.0155139 + 0.1738515; 0.0354616 + 
1155644; -0.0509683 + —-0.201625j; 0.0107812 + 0.03590634; 0.0892584 + 0.2085134; - 
-0485137 + -0.007887964; 
PDU octect 45: -0.0350413 + 0.04419423; 0.0170981 + -0.058969j; 0.0529809 + -0.0169834)3; 
0 
0 
D 
0 
0 








987838 + 0.1001545; 0.034056 + -0.1483795; -0.00283341 + -0.09401293; -0.120297 + 
4195075; -0.136448 + -0.06986563; 
U octect 46: -0.03125 + 03; -0.136448 + 0.069865645; -0.120297 + -0.04195084; - 
028334 + 0.09401295; 0.0340559 + 0.1483795; 0.0987838 + -0.1001544; 0.0529809 + 
1698345; 0.0170981 + 0.0589693; 
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PPDU octect 47: -0.0350413 + -0.04419425; -0.0485138 + 0.007887954; 0.0892585 + - 
0.2085134; 0.0107813 + -0.03590634; -0.0509683 + 0.2016254; 0.0354616 + -0.1155643; 
0.0155138 + -0.1738513; 0.0572128 + -0.05249733; 

PPDU octect 48: 0.0625 + 04; 0.0330338 + -0.04385274; -0.00196556 + -0.0376274; 
0.0809046 + 0.08443053; 0.00677414 + -0.1001514; -0.00124631 + -0.1133023; -0.0211465 + - 
0.004640194; 0.135693 + -0.104693; 

PPDU octect 49: 0.0975413 + -0.04419424; 0.0112075 + -0.0018325945; -0.0327044 + 
0.04407994; -0.0604833 + 0.1242274; 0.0101382 + 0.09660194; 0.000441049 + -0.007769564; 
0.0183601 + -0.08250373; -0.0692837 + 0.02673354; 

PPDU octect 50: -0.0592927 + 0.1004254; 0.00409242 + 0.01397114; 0.0109037 + -0.1002624; 
-0.0969928 + -0.02034574; 0.0621235 + 0.081384; 0.123595 + 0.1389173; 0.104256 + - 
0.01505524; 0.172935 + -0.1397913; 

PPDU octect 51: -0.0395934 + 0.005853774; -0.133488 + 0.008928843; -0.00158766 + - 
0.04328464; -0.0472771 + 0.09216564; -0.109013 + 0.08170543; -0.0239633 + 0.01040723; 
0.0964961 + 0.01854893; 0.0191099 + -0.02257153; 

PPDU octect 52: -0.0873354 + -0.04941064; 0.00234121 + 0.05812534; -0.0210441 + 
0.2284574; -0.102889 + 0.02282454; -0.0192593 + -0.1751544; 0.0178246 + 0.1317744; 
0.0710194 + 0.160384; -0.15319 + -0.06192584; 

PPDU octect 53: -0.107073 + 0.02788594; 0.055435 + 0.1400184; 0.069911 + 0.1026844; - 
0.0555579 + 0.02490163; -0.0427567 + 0.001620334; 0.0156848 + -0.1180584; 0.0255435 + - 
0.07124844; 0.0332799 + 0.1772293; 

PPDU octect 54: 0.0197642 + -0.02136793; 0.0353311 + -0.08842214; -0.00812379 + 
0.1006984; -0.0349064 + -0.009642464; 0.0646485 + 0.03042344; 0.0924734 + -0.03388424; 
0.0319434 + -0.1225353; -0.0175289 + 0.09169163; 

PPDU octect 55: 6.49395e-05 + -0.005853763; -0.00622475 + -0.05610294; -0.019328 + 
0.03975774; 0.0532 + -0.1313784; 0.021769 + -0.1328113; 0.104157 + -0.03173; 0.162671 + - 
0.04451164; -0.10486 + -0.0295873; 

PPDU octect 56: -0.110307 + -0.06917483; -0.00773789 + -0.09188393; -0.0492151 + - 
0.04282844; 0.0847025 + -0.01723794; 0.0901296 + 0.06335083; 0.01488 + 0.1533763; 
0.0486094 + 0.09380873; 0.011148 + 0.03397753; 

PPDU octect 57: -0.0115127 + 0.01164264; -0.0152419 + -0.01738053; -0.0605729 + 
0.03100654; -0.0701968 + -0.04034413; 0.0114148 + -0.1086283; 0.03707 + -0.059970934; - 
0.00321576 + -0.1775023; -0.00720509 + -0.1280794; 

PPDU octect 58: -0.0592927 + 0.1004254; 0.00409242 + 0.01397114; 0.0109037 + -0.1002624; 
-0.0969928 + -0.02034574; 0.0621235 + 0.081384; 0.123595 + 0.1389173; 0.104256 + - 
0.01505524; 0.172935 + -0.1397913; 

PPDU octect 59: -0.0395934 + 0.005853774; -0.133488 + 0.008928843; -0.00158766 + - 
0.04328464; -0.0472771 + 0.09216564; -0.109013 + 0.08170543; -0.0239633 + 0.01040723; 
0.0964961 + 0.01854894; 0.0191099 + -0.02257153; 

PPDU octect 60: -0.0296464 + 0.08066063; -0.0963844 + -0.04503474; -0.1102 + 0.002881394; 
-0.0700095 + 0.2157473; -0.0396332 + 0.05939584; 0.00997518 + -0.05551773; 0.0337749 + 
0.06526934; 0.11684 + 0.03322853; 

PPDU octect 61: 0.0779988 + -0.1331983; -0.0427866 + -0.1461734; 0.158107 + -0.07050244; 
0.253711 + -0.02106393; 0.067816 + 0.1169814; -0.0441807 + 0.1142554; -0.0354926 + 
0.04104363; 0.0845137 + 0.07018783; 

PPDU octect 62: 0.120189 + 0.009882123; 0.0573284 + 0.05463684; 0.0632006 + 0.1878343; 
0.0906149 + 0.1493914; -0.0165717 + -0.03938764; -0.0775449 + -0.07495324; 0.0494644 + 
0.07926234; -0.0139247 + -0.007280123; 

PPDU octect 63: 0.0302837 + -0.02731353; 0.080169 + 0.05373033; -0.185944 + -0.06671724; 
-0.0386776 + -0.02743934; 0.0430363 + -0.07180344; -0.0919199 + -0.0894214; 0.0290079 + 
0.1053914; -0.144236 + 0.00338993; 

PPDU octect 64: -0.0691748 + -0.04113213; 0.131827 + 0.05664974; -0.126439 + 0.06974654; 
-0.0308446 + 0.1086883; 0.160616 + -0.009282964; 0.0555444 + -0.04626414; -0.00366729 + 
0.02784594; -0.0492698 + 0.0001491473; 

PPDU octect 65: -0.0779988 + -0.005151464; 0.0145183 + -0.08708463; 0.148909 + - 
0.1039974; -0.0212099 + -0.05148824; -0.154066 + -0.1063973; 0.02395 + 0.03033624; 
0.0463352 + 0.1229834; -0.00377208 + -0.09839074; 

PPDU octect 66: -0.0608964 + -0.1284684; -0.0236949 + -0.03805314; 0.0664307 + - 
0.04843234; -0.0671134 + 0.02662014; 0.0537023 + -0.05025374; 0.170927 + -0.04869263; - 
0.107523 + 0.1322734; -0.161486 + -0.01943663; 

PPDU octect 67: -0.0698122 + -0.07150773; -0.176879 + 0.04911594; -0.172178 + - 
0.04986984; 0.0512337 + -0.07463614; 0.122271 + -0.05736643; 0.00915009 + -0.04375854; - 
0.0118996 + -0.02066964; 0.00363008 + 0.008560914; 

PPDU octect 68: -0.0296464 + 0.08066063; -0.0963844 + -0.04503474; -0.1102 + 0.002881394; 
-0.0700095 + 0.2157473; -0.0396332 + 0.05939584; 0.00997518 + -0.05551773; 0.0337749 + 
0.06526934; 0.11684 + 0.03322853; 

PPDU octect 69: 0.0779988 + -0.1331984; -0.0427866 + -0.1461734; 0.158107 + -0.07050244; 
0.253711 + -0.02106393; 0.067816 + 0.1169814; -0.0441807 + 0.1142554; -0.0354926 + 
0.04104364; 0.0845137 + 0.07018784; 
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PPDU octect 
0.123994 + 

0.003879333 
PPDU octect 
0.045245735; 
0.0827078 + 
PPDU octect 
0.0227295 + 
0.037920735; 
PPDU octect 
0.021491134; 
0.0263911 + 
PPDU octect 
0.0158528 + 
0.033908835; 
PPDU octect 
0.058091935; 
0.075177 + 

PPDU octect 
=0.115934 4+ 
0.064045435; 
PPDU octect 
0.0420396 + 
0.020705535; 
PPDU octect 
0.123994 + 

0.003879333 
PPDU octect 
0.045245735; 
0.0827078 + 
PPDU octect 
0.12597 4S = 
0.055620935; 
PPDU octect 
0.0448767 + 
0.011466435; 
PPDU octect 
0.124333 + 

0.0994033; 

PPDU octect 
0.146588 + 

0.099688535; 
PPDU octect 
0.04832063; 
#0, 0307125 

PPDU octect 
0.155152 + 

0.018052235; 
PPDU octect 
0.0498857 + 
009917385; 
PPDU octect 
0.0646191 + 
0.12441235; 

PPDU octect 
QO.12597 = 
0.05562093; 
PPDU octect 
0.0448767 + 
0.011466435; 
PPDU octect 
0.070843435; 
0.0084312 + 
PPDU octect 
0.0869275 + 
0.0363493; 

PPDU octect 
0.09867863; 
0.0604381 + 





























70: -0.118585 + 0.0114858j; -0.0994333 + -0.047962j; 0.0536084 + -0.1960793; 
0.0345825j; 0.0919315 + 0.044989543; -0.036786 + -0.0658418j3; -0.0211003 + - 

7 0.0424973 + -0.06490113; 

71: 0.0611289 + 0.0482766j; 0.0463064 + 0.004173444; -0.0628931 + - 

-0.101784 + 0.1522745; -0.0392474 + -0.01870275; -0.00526792 + -0.106066j; 
0.03057965; 0.225664 + 0.0276615j; 

72: 0.139953 + -0.0098821135; -0.132354 + -0.03290923; -0.116179 + 0.08833094; 
0.05183963; -0.171248 + -0.0803886 3; -0.245748 + -0.02459084; -0.0624398 + - 
-0.0549765 + -0.062213; 

73: -0.00395256 + -0.05985423; 0.0338285 + -1.12667e-05j; -0.0302122 + 
0.0747573 + -0.121648 5; 0.04317 + -0.07961053; -0.0224231 + 0.04145473; 
0.01311293; -0.03097 + -0.01845443; 

74: 0.0592927 + 0.008278485; 0.108935 + 0.077986135; 0.00206425 + 0.101085j; - 
0.05406593; -0.059185 + 0.07020493; 0.0168651 + 0.114138 5; 0.103643 + - 
-0.0242415 + -0.05890053; 

75: -0.0808932 + 0.05054453; -0.0402822 + —-0.0687858 4; -0.0685797 + 
-0.067265 + 0.1172315; 0.00650102 + -0.1312255; 0.00858317 + 0.0280095j; 
0.1167675; 0.117563 + 0.02966943; 

76: -0.0411321 + 0.1482325; 0.00497321 + 0.09760943; 0.0257738 + 0.0018678534; 
0.0446468 5; -0.0196118 + 0.08377963; 0.100749 + 0.0062555345; 0.20549 + - 
0.0729341 + -0.06330134; 

77: -0.173926 + -0.1180243; -0.0241854 + 0.0258011j; -0.040753 + 0.1285723; 
-0.05348395; 0.14769 + -0.12621835; -0.0299877 + -0.04926093; -0.0145844 + - 
0.0891527 + -0.06907224; 

78: -0.118585 + 0.01148584; -0.0994333 + -0.0479623; 0.0536084 + -0.1960793; 
0.0345825j; 0.0919315 + 0.0449895 3; -0.036786 + -0.0658418 4; -0.0211003 + - 

7 0.0424973 + -0.06490113; 

79: 0.0611289 + 0.0482766j; 0.0463064 + 0.004173443; -0.0628931 + - 

-0.101784 + 0.1522745; -0.0392474 + -0.01870275; -0.00526792 + -0.106066j; 
0.0305796j; 0.225664 + 0.02766153; 

80: 0.0296464 + -0.1201895; 0.0340277 + -0.1424614; 0.00366307 + -0.01231233; 
0.04297293; 0.0545228 + 0.068021353; -0.0196314 + 0.07724275; 0.00787072 + - 
-—0.0343327 + 0.04616553; 

81: -0.0396692 + -0.13382543; -0.056498 + -—0.13112435; 0.0143079 + 0.09666733; 
-0.008587075; -0.112614 + -0.170493; -0.065255 + -0.2296763; 0.0651514 + - 





0.011351 + 0.0475734; 

82: -—0.0905427 + -0.059292735; 
0.021544845; -0.0371767 + 0.0707535 
—0.0620882 + 0.06822453; 














—0.109871 + 0.02442135; 








0.0153654 


ji 


0.0738487 + -0.03434583; 
0.00152866j; 0.0280382 + 











83: 0.0639476 + 0.01623255; 0.0781643 + 0.1560225; 0.00886139 + 0.219155j; 
0.02388225; 0.105724 + 0.03037613; -0.0804061 + 0.1427883; -0.048684 + - 
-—0.0360851 + -0.08227083; 

84: -—0.0889391 + 0.02136795; -0.0700184 + -0.02935563; -0.0862983 + 
-0.0657101 + -0.015474735; -0.0241742 + 0.001855815; -0.0304487 + -0.02302623; 
+ 0.0199536j; -0.00206234 + 0.2118113; 

85: 0.158255 + -0.02428924; 0.141453 + -0.1186093; -0.1461 + 0.057527235; - 
0.08333293; -0.0015876 + -0.0295499j; 0.018425 + -0.1293053; 0.012172 + - 
-0.0083002 + -0.03718994; 

86: 0.03125 + 0.03952855; 0.0234214 + 0.096582135; 0.0135822 + -0.03920453; 
0.018932745; -0.0722289 + -0.1406313; -0.0228469 + -0.0508914j3; 0.0237545 + 
-0.127134 + -0.1161933; 

87: 0.0941663 + 0.1023534; 0.182928 + 0.09821425; -0.0399674 + -0.01957943; 
0.0774563; 0.0875343 + -0.146564j; -0.038809 + -0.0585788j; -0.0565902 + 
-0.0767586 + 0.01999334; 

88: 0.0296464 + -0.1201895; 0.0340277 + -0.14246135; 0.00366307 + —-0.01231234; 
0.04297295; 0.0545228 + 0.06802134; -0.0196314 + 0.07724273; 0.00787072 + - 
-0.0343327 + 0.04616553; 

89: -0.0396692 + —-0.133825j; -0.056498 + -0.131124j; 0.0143079 + 0.09666733; 





-0.008587075; -0.112614 + -0.1704 
0.011351 + 0.0475734; 

90: 0.0395285 + 0.01816063; 
-0.0373389 + -0.1169393; -0.10566 
-0.01097015; 0.0187883 + 0.072153 
91: 0.0162325 + 0.05873113; 
0.0254595; -0.00262285 + -0.10286 
-0.0296711 + -0.0030954834; 





95; 


-0.00163598 + 0.04127953; 
0.00181488 + 0.05680873; 


4 + -0.06233; 
95; 


-0.0652257 + -0.07669814; 


53; 0.106662 + 


-0.065255 + -0.2296763; 


0.0651514 + - 


0.00138841 + 


0.141542 + -0.0617811j4; 
-0.1516833; -0.0544175 + 


-0.027348 + - 


92: 0.0576891 + —-0.01976423; 
0.0487899 + -0.0752348); 
0.0766523; 


0.174449 + 0.03084293; 
-0.0104721 + -0.02183014; 


-0.0278851 + 0.00667214; 
0.133943 + 0.1555553; 
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PPDU octect 93: -0.0835819 + 0.040094; -0.073946 + 0.01105314; -0.163122 + 0.05409384; - 
0.0520085 + -0.008318974; 0.0762527 + -0.04192794; 0.0425213 + 0.1009444; 0.0576176 + - 
0.01832524; 0.00311136 + -0.08991093; 

PPDU octect 94: 0.0592927 + -0.01816064; 0.0230726 + -0.03093624; 0.00711971 + - 
0.01721564; 0.066082 + -0.0168973; -0.13531 + -0.09821174; -0.0556543 + -0.08077993; 
0.0885568 + 0.1543514; 0.119511 + 0.1223363; 

PPDU octect 95: 0.102353 + 0.0005615784; -0.141042 + 0.1021044; 0.0063104 + -0.01140423; 
0.0566463 + -0.03935823; -0.0590676 + 0.0657344; 0.131893 + 0.1111023; 0.0119852 + 
0.1137664; 0.0468643 + -0.1059963; 

PPDU octect 96: 0.159718 + -0.09882123; -0.076392 + 0.08449073; -0.0486395 + 0.07300164; 
0.00507324 + -0.08613913; -0.0520616 + -0.1075024; -0.0726498 + 0.1287664; -0.128986 + - 
0.03396844; -0.15277 + -0.110953; 

PPDU octect 97: -0.193117 + 0.09825963; -0.107315 + -0.06849934; 0.00369191 + - 
0.008859414; -0.0392129 + 0.02435544; -0.0540907 + -0.07905534; 0.023725 + 0.08416244; 
0.052294 + -0.001626373; 0.0277925 + -0.04397594; 

PPDU octect 98: 0.0395285 + 0.01816063; -0.00163598 + 0.04127954; 0.00138841 + 
0.07084344; -0.0373389 + -0.1169394; -0.105664 + -0.06234; 0.00181488 + 0.05680873; - 
0.0084312 + -0.01097013; 0.0187883 + 0.07215393; 

PPDU octect 99: 0.0162325 + 0.05873113; -0.0652257 + -0.07669814; 0.141542 + -0.06178114; 
0.0869275 + 0.0254594; -0.00262285 + -0.1028654; 0.106662 + -0.1516834; -0.0544175 + 
0.03634943; -0.0296711 + -0.003095483; 

PPDU octect 100: 0.0197642 + -0.1597184; 0.0290886 + 0.02525474; 0.0861483 + -0.02883494; 
0.0867942 + -0.08151423; 0.00345816 + -0.03599474; -0.0960365 + -0.08859534; -0.0729433 + 
-0.04590313; 0.105487 + -0.01966363; 

PPDU octect 101: 0.192621 + 0.01800383; -0.0531459 + -0.0731014; -0.118339 + -0.1488854; 
0.0191895 + -0.019092945; -0.0417141 + 0.02637564; 0.0405524 + 0.008824314; 0.0284543 + - 
0.07647564; -0.0376039 + -0.06841933; 

PPDU octect 102: -0.0114858 + 0.009882124; -0.133529 + -0.06448794; 0.0689293 + - 
0.06717224; 0.0570357 + 0.006300214; -0.134364 + 0.09801073; 0.152477 + 0.03607623; 
0.0412595 + -0.08454334; -0.099111 + -0.04858334; 

PPDU octect 103: 0.089004 + -0.09945853; -0.0459865 + 0.01818254; -0.112344 + 0.1354814; 
-0.0635739 + 0.01785064; -0.0222531 + 0.05300814; 0.0410498 + 0.07654944; -0.0211672 + 
0.1446444; 0.00665332 + 0.1787823; 

PPDU octect 104: 0.0592927 + 0.04113213; 0.0225525 + 0.06445874; 0.0616463 + 0.02174854; 
0.110484 + -0.08067793; -0.016029 + -0.05364664; -0.0138699 + -0.01747743; 0.171277 + 
0.008076644; 0.0701664 + -0.0267874; 

PPDU octect 105: -0.0147426 + 0.001760444; -0.0124264 + 0.05290653; -0.125061 + 
0.008719654; -0.039783 + 0.01238334; 0.0359253 + 0.1143724; 0.00701687 + 0.08986293; - 
0.0158081 + -0.08224873; -0.00846144 + -0.01293393; 

PPDU octect 106: 0.0905427 + 0.02964634; 0.0723212 + -0.06830323; 0.0512069 + 0.06268113; 
-0.0042373 + 0.04863634; -0.129764 + -0.04789784; -0.120922 + 0.06142773; -0.0952694 + 
0.07804574; 0.0106693 + 0.004565154; 

PPDU octect 107: 0.0493456 + 0.0006373344; -0.0138327 + -0.01081213; 0.00875645 + - 
0.06279494; -0.030951 + 0.04021294; -0.0114865 + 0.003886783; -0.0334234 + -0.1107664; 
0.11486 + 0.13746145; -0.0246448 + 0.04894173; 

PPDU octect 108: 0.0197642 + -0.1597184; 0.0290886 + 0.02525474; 0.0861483 + -0.02883494; 
0.0867942 + -0.08151423; 0.00345816 + -0.03599474; -0.0960365 + -0.08859534; -0.0729433 + 
-0.04590315; 0.105487 + -0.01966363; 

PPDU octect 109: 0.192621 + 0.01800383; -0.0531459 + -0.0731014; -0.118339 + -0.1488854; 
0.0191895 + -0.019092945; -0.0417141 + 0.02637564; 0.0405524 + 0.008824313; 0.0284543 + - 
0.07647564; -0.0376039 + -0.06841933; 
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Phew! It finally works 


KKEKKKKKKKKKKKKKKKKKKKK KKK KKK KK KKK KKK 


802.1la PPDU transmission 
KKKKKKKKKKKKKKKKKKKKKKKKKEKKEKKKKKKKAKK 


End of OSSIE simulation: 
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B. RECEIVER 


KKEKKKKKKKKKKKKKKKKKKKKKKKKK KKK KKK KKK 


Welcome to OSSIE simulation: 802.1la PPDU receiver 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Start PPDU digitised receiver 

stream_sizeI = 884, stream_sizeQ = 884 

Removed preamble from PPDU samples 

Preamble match at pointer: 4 

Sent PPDU (preamble removed) samples 
PPDU_preamble_removed data, Length 560 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start PPDU Header remove function 

KKK KKK KK KK KKK KKKKKEKKKKKKKKKKKKAKKKKK 

Complex float pushpacket received, length 560 
Sent SIG time samples for processing ... 
Header removed data output, Length 80 

KKK KKK KKK KK KKK KK KK KKKKKKEKKEKKKKKKKKKK 


Start SIG_cyclicPrefix_rem function 

KKK KKK KKK KKK KKK KKKEKKKKKKKEKKKAKKAKKKKK 

Complex float pushpacket received, length 80 
Processing SIG cyclic prefix remove 
SIG_cyclicPrefix_rem Tx data, Length 64 

KKK KKK KKK KK KK KKKKKEKKKKKKKKKKKKKKKKK 


Start SIG_FFT function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
Complex float pushpacket received, length 64 
Processing SIG FFT 

FFT frequency output (Magnitude), Length 64 
SIG_FFT Tx data, Length 64 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIG_carriers_demap function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Complex float pushpacket received, length 64 
Processing carrier demapping 

SIG carriers demapped data, Length 48 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIG_demodulation function 
KKK KKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKK 








Complex float pushpacket received, length 48 
Processing SIG BPSK demodulation 
SIG demodulated data, Length 48 


KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIG_deinterleaver function 

KKK KKK KK KK KKK KKKEKKEKKEKKKKKKKKAKKAKKKKK 

Real short pushpacket received, length 48 
Processing SIG deinterleaver, size: 48 
SIG deinterleaved Tx data, Length 48 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start SIG convolution decoding function 
KEKE KKK KKK KKK KKK KEK KEKKKKKEKKEKKKAKKAKKKKK 

Real short pushpacket received, length 48 
Processing SIG convolution decoding, size: 48 
We are inside initialise_viterbi 

Nstate = 64; Nsr = 6 

return from initialise viterbi 

We are inside process_viterbi 

No. of iterations: 24 

return from process viterbi 

End of decoding 

SIG decoded Tx data, Length 24 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


SIG header information received 

KKK KKK KK KK KKK KKKKKEKKKKKKKKKKAKKKKKKK 

Real short pushpacket received, length 24 

Processing Data sequence, rate: 36 Mbit/s, length: 100 octets 
Send raw data for decoding 

Header removed data output, Length 485 


KKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data recovery function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 
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Complex float pushpacket received, length 485 
Sent raw data for processing 
Data output, Length 485 


KKEKKKKKKKKKKKKKKKKKKKK KKK KKK KKK KK KKK 


Start Data_cyclicPrefix_rem function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Complex float pushpacket received, length 485 
Processing Data cyclic prefix remove 
Data_cyclicPrefix_rem Tx data, Length 389 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_FFT function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Complex float pushpacket received, length 389 
Processing Data FFT 

FFT frequency output (Magnitude), Length 384 
Data_FFT Tx data, Length 389 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_carriers_demap function 

KKK K KKK KKK KKK KKKKKKEKKKKKKKKKKAKKAKKKKK 

Complex float pushpacket received, length 389 
Processing data carrier demapping 

Data carriers demapped data, Length 293 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_demodulation function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Complex float pushpacket received, length 293 
Processing Data demodulation 

Conduct 16QAM demodulation 

Data demodulated data, Length 1157 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data_deinterleaver function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

Real short pushpacket received, length 1157 
Processing Data deinterleaver 

Data deinterleaved Tx data, Length 1157 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Start Data convolution decoding function 
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Real short pushpacket received, length 1157 
Processing Data convolution decoding 

Recover the punctured encoded Data, size: 1152 
We are inside initialise_viterbi 

Nstate = 64; Nsr = 6 
return from initialise viterbi 
We are inside process_viterbi 
No. of iterations: 144 
We are inside process_viterbi 
No. of iterations: 144 
We are inside process_viterbi 
No. of iterations: 144 
We are inside process_viterbi 
No. of iterations: 144 
We are inside process_viterbi 
No. of iterations: 144 
We are inside process_viterbi 
No. of iterations: 144 
return from process viterbi 

End of decoding 

Data decoded Tx data, Length 869 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 

















Start Data_descrambler function 

KEKE KKK KKK KKK KKKKKKEKKKKKKKKKKAKKAKKKKK 

Real short pushpacket received, length 869 
Processing data in the descrambler 
Descrambled data Bits, Length 864 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 





Decoded Data received 

KKK K KKK KKK KKKKKKKKKEKKKKKKKKKKAKKAKKKKK 

Real short pushpacket received, length 864 
Send PSDU data to MAC layer ... 

PSDU Data output, Length 801 
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KKEKKKKKKKKKKKKKKKKKKK KKK KKK KKK KKK KKK 


Start Data_PSDU display function 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


length 801 
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Real short pushpacket received, 
Start PSDU display 
data successfully decoded: 


04 
02 
00 
2e 
00 
60 
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Received 
Received 
Received 
Received 
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Phew! 
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It finally works 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


End of OSSIE simulation: 
KKK KK KK KKK KKK KKK KKK KKKKKKKKKKAKKKKKKK 
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802.1lla PPDU receiver 
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APPENDIX D: IEEE 802.11A TEST SEQUENTIAL FLOW CHART 


A. TRANSMITTER 





























IEEE 802.11a Transmitter components sequential flow Example (802.11a Annex G) 
Components Description Data In | Type In | Data Out | Type Out| Data size in | Data size out 
- initiate the tx routine 
1|preamble_map - start ST sequence processing - - complex | integer - 52 
2\ST_carrier_map - ST carrier mapping complex | integer | complex float 52 64 
3\ST_IFFT - ST IFFT complex float complex float 64 160 
- receive ST samples 
4preamble_map - start LT sequence processing complex float complex | integer 160 52 
5|LT_carrier_map - LT carrier mapping complex | integer | complex float 52 64 
6LT_IFFT - LT IFFT complex float complex float 64 128 
7|LT_cyclicPrefix - LT cyclic prefix append complex float complex float 128 160 





- receive LT samples 
- send preamble (ST + LT) to 





















































8|preamble_map PPDU complex float complex float 160 320 
- receive preamble 
9IPPDU_map - send CB to start SIG processing | complex float real integer 320 8 
- receive RATE & LENGTH 
10\lheader_map - send raw SIG for processing real integer real integer 8 24 
11/SIG_conv_enc - SIG convolution encoding real integer real integer 24 48 
12/SIG_interleaver - SIG interleaving real integer real integer 48 48 
13/SSIG_BPSK_mod - SIG BPSK modulation real integer | complex float 48 48 
14/SIG_carriers_map - SIG carriers mapping complex float complex float 48 64 
15/SIG_IFFT - SIG IFFT complex float complex float 64 64 
16/SIG_cyclicprefix - SIG cyclic prefix complex float complex float 64 80 
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Example (802.11a Annex G) 





















































Components Description Data In | Type In | Data Out | Type Out| Data size in | Data size out 
- receive SIG samples 
17lheader_map - send SIG to PPDU complex float complex float 80 96 
- receive SIG samples 
18IPPDU_map - send CB to start data processing | complex float real integer 96 24 
- receive RATE & LENGTH 
- send CB to start PSDU 
19\data_map processing real integer real integer 24 24 
20idata_PSDU - input PSDU data real integer real integer 24 800 
- receive PSDU data 
- send CB to start PSDU 
21\data_map processing real integer real integer 800 869 
22\data_scrambler - scrambler the raw data real integer real integer 869 869 
23idata_tail_replacement - replace tail with zeroes real integer real integer 869 869 
- data convolution encoding 
24data_conv_enc - data puncturing real integer real integer 869 1157 
25data_interleaver - data interleaving real integer real integer 1157 1157 
26\data_mod_map - data modulation mapping real integer | complex float 1157 293 
27\data_carriers_map - data carriers mapping complex float complex float 293 385 
28idata_IFFT - data IFFT complex float complex float 385 385 
29data_cyclicprefix - data cyclic prefix complex float complex float 385 480 
- receive time data samples 
30\data_map - send time data samples to PPDU | complex float complex float 480 480 
- receive time data samples 
- form PPDU packet for 
31/PPDU_map transmission complex float complex float 480 880 
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B. RECEIVER 
























































IEEE 802.11a Receiver components sequential flow Example (802.11a Annex G) 
(Components Description Data In | Type In |Data Out Type Out| Data size in | Data size out 
1|Rx_data - received digitised data stream - - complex | ___ float - continuous 
- extract the required digitised 
PPDU stream 
- removed preamble from PPDU 
2/PPDU_rx - send stream for header removal | complex |_ float | complex | _ float continuous 560 
- removed header from PPDU 
3/Header_rx - send header for processing complex |__float_ | complex | __ float 560 80 
4/SIG_cyclicprefix_rem - SIG cyclic prefix removal complex |_ float | complex | __ float 80 64 
5|SIG_FFT - SIG FFT complex | float | complex | __ float 64 64 
6|SIG_carriers_demap - SIG carriers demapping complex | __ float | complex | _ float 64 48 
7\SIG_BPSK_demod - SIG BPSK demodulation complex | __ float real integer 48 48 
8iSIG_deinterleaver - SIG deinterleaving real integer real integer 48 48 
9ISIG_conv_dec - SIG convolution decoding real integer real integer 48 24 
- extract RATE & LENGTH from 
SIG 
- send received data for 
10\Header_rx processing real integer | complex | __ float 24 485 
- receive and send raw data for 
11|\data_rx processing complex |__ float | complex | __ float 485 485 
12\data_cyclicprefix_rem - data cyclic prefix removal complex | float | complex | float 485 389 
13\data_FFT - data FFT complex | _ float | complex | __ float 389 389 
14\data_carriers_demap - data carriers demapping complex |__ float | complex | __ float 389 293 
15\data_demod_map - data demodulation mapping complex | ___ float real integer 293 1157 
16\data_deinterleaver - data deinterleaving real integer real integer 1157 1157 
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